Assert is one of the (several) best friend of every developer. Asserts are widely useful from checking pre-conditions to post-conditions and every other possible assumptions/invariants in between.
When an assert condition fails, it usually indicates a serious error and is a way for the program to scream back at the developer “There’s a massive breach of contract here and the result isn’t likely to be pretty”… Historically, asserts failures tend to manifest themselves quite catastrophically such as aborting the program mid-execution or displaying a severe looking pop-up for graphical softwares.
In ASP.NET with IIS previous to version 7, it used to be the same, you would get an annoying ugly massive pop-up on the server (usually a developer’s machine given that the .NET Debug.Assert is only executed in debug mode). Now, I can see how this can cause problems to people using debug builds on servers (probably not the smartest) or using one testing server for several developer in which case the server hangs awaiting for someone to click the “OK” button on the pop-up !
In IIS 7, there is no ugly annoying pop-up anymore, the assertion kindly display in the Output window of Visual Studio if you are attached to the process or you can redirect them to a trace file if you prefer. This is all fine and clearly has some use for some people, but to me, it kills the first and most important aspect of a failed assert: it’s got to be in your face and annoying enough that the developer cannot a) miss it and b) ignore it.
The IIS7 behaviour misses the point on both accounts as not everyone is going to happen to look at the output window all the time during debugging and it is way too easy to ignore it — just don’t look at it. Finally, it also means that unless you are actually attached to the process you will not see the assert. Even if you happened to see the assert after the fact, it is of a lot less use since you don’t have the process at hand with the call-stack and frames to do anything useful if the problem is not excessively trivial.
I had already wrapped all my calls to Debug.Assert into a conditional method so that I could easily intercept/add a behavior to those calls such as sending emails to the development mailing list for example. So it was rather easy to restore the original catastrophic behavior of the assert with the following:
1 [System.Diagnostics.Conditional( "DEBUG" )]
2 public static void Assert(Boolean condition, String message)
4 if ( !condition )
6 System.Diagnostics.Debug.Assert( condition, message );
This nicely abort the thread which should catch any developer’s attention 🙂 The conditional attribute on DEBUG insures that the method is removed from release builds where DEBUG is not defined in a similar fashion as Debug.Assert is.
I have searched for a good while and I have not seen anyway of configuring the Debug.Assert behavior to be either the old or the new way which would be very useful. If anyone knows how to do this, I’d be very interested in hearing it.