Two words: "Legacy Code." The only time I've used Debug.Assert is with legacy code with zero tests.

I hardly use Debug.Asserts these days. I rather throw a descent Exception. Last few months I even switched to throwing EnsuresViolationExceptions (I borrowed the concept from Spec#) when my code fails to deliver it's post condition.

Can you explain in what situations you use asserts instead of throws?

Interesting.. I've been debating the issue of the Debug.Assert statements with colleagues lately. We're actually using TDD while writing a new (large) application. I don't think Debug.Assert statements are evil, so I quite agree with your bottom line. However, my justification is different: I want to tell the developers when they're not respecting some pre-condition to this piece of code. That's why I want a Debug.Assert statement here. It happens to me every day. I'm writing a piece of code to make some acceptance test and unit test go green. Let's say that the code retrieves an instance of some domain object that, in all cases considered by the acceptance tests, is guaranteed to exist. Then, the code needs to check a property on that instance. As I write the code, because I am paranoid, I instinctively wonder what to do if the instance is null (because calling a method or property on a null reference would bomb). Usually, I'd write a unit test showing the behavior of that method when the instance is null, but I have no acceptance test triggering that, and -for the sake of argument- let's say that, it is really impossible for that to happen when we consider the application as a whole. Heck, I could use predicate calculus to prove it to you: that instance will never be null under all circumstances in which (at this point in time) that method can be called. So we can't quite write a meaningful acceptance test to trigger that null condition. Therefore we shouldn't need to write the code for it, nor a unit test for it. That's when I like to put a Debug.Assert statement. If, later on, a colleague calls that method under different conditions that, suddenly, make it possible for that null condition to happen, they'd get the error message from my Debug.Assert statement (e.g.: such and such instance was unexpectedly null), and they'd be able to figure out what's going on without having to debug and trace.

My general pattern has been asserts for private methods, unit tests for public. Is this wrong?

I used to use Debug.Assert a lot but these days I just throw exceptions when preconditions are violated, I haven't found any situations where I haven't wanted the test to run in production but that seems like a situation where using Debug.Assert is still useful.

@David That doesn't seem wrong to me. Thinking back when I've written reasonably complex classes I have found issues using Asserts in private methods, things that the (exception raising) preconditions on the public methods and the unit tests had missed. So yeah it can be useful, though I guess it depends on the complexity of the issue.

@David: exactly my philosophy. Unit tests cover my public APIs. Assertions ensure my private APIs are being called with correct parameters, consistent state etc. My unit tests probably will catch any issues, but the mere fact that Debug calls are optimized out of Release builds means it's win / win.

Assertions are indeed handy when you want to be fault restrictive in development-mode and fault-tolerant in production-mode. I do log failures though. Currently I'm writing something that has to go through binary data. Under development I want to know when some unexpected comes along, in production you wouldn't hardly notice in most cases if some incoming data was interpred incorrectly.

I know this is a very specific reason to use Debug.Assert(), but in ASP.NET hosted applications I like to throw one on the un-handled global exception event handlers you can setup. That way while running a debug build on my workstation I get an assertion. Of course, these handlers are also logging and redirecting to friendly error pages and such.

Today was another public holiday. It was boring and I tried to hack NAnt to build with multiple threads

Hangovers are evil.

Pingback from  Interesting Finds: January 28, 2008 « Hank Wallace