.Net equivalent to Java's AssertionError

Question

In Java, I will occasionally throw an AssertionError directly, to assert that a particular line will not be reached. An example of this would be to assert that the default case in a switch statement cannot be reached (see this JavaSpecialists page for an example).

I would like to use a similar mechanism in .Net. Is there an equivalent exception that I could use? Or is there another method that could be used with the same effect?

Edit - To clarify, I'm looking for a mechanism to flag failures at runtime, in released code, to indicate that there has been a (possibly catastrophic) failure of some invariant in the code. The linked example generates a random integer between 0 and 2 (inclusive) and asserts that the generated number is always 0, 1 or 2. If this assertion doesn't hold, it would be better to stop execution completely rather than continue with some unknown corrupt state of the system.

Answer 1

Debug.Assert(false);

Answer 2

I'd normally throw InvalidOperationException or ArgumentOutOfRangeException depending on where the value came from.

Alternatively, there's Debug.Assert (which will only fail when you've got the DEBUG preprocessor symbol defined) or in .NET 4.0 you could use Contract.Fail, Contract.Assert or Contract.Assume depending on the situation. Explicitly throwing an exception has the benefit that the compiler knows that the next statement is unreachable though.

I'm not a big fan of Debug.Assert - it's usually inappropriate for a release (as it throws up an assertion box rather than just failing) and by default it won't be triggered in release anyway. I prefer exceptions which are always thrown, as they prevent your code from carrying on regardless after the opportunity to detect that "stuff is wrong".

Code Contracts changes the game somewhat, as there are all kinds of options for what gets preserved at execution time, and the static checker can help to prove that you won't get into that state. You still need to choose the execution time policy though...

Answer 3

Debug.Assert() method.

System.Diagnostics.Debug.Assert(false);

Answer 4

You can use the Trace.Assert method, which will work on release builds (if you have the TRACE compilation symbol defined, which is defined by default on VIsual Studio projects). You can also customize the way your application reacts on assertion errors by way of a TraceListener. The default is (unsurprisingly) the DefaultTraceListener, which will show the assertion in a dialog box if the application is running in interactive mode. If you want to throw an exception, for example, you can create your own TraceListener and throw it on the method Fail. You can then remove the DefaultTraceListener and use your own, either programmatically or in the configuration file.

This looks like a lot of trouble, and is only justifiable if you want to dynamically change the way your application handles assertions by way of the trace listeners. For violations that you always want to fail, create your own AssertionException class and throw it right away.

For .NET 4.0, I'd definetely look at the Contract.Assert method. But, this method is only compiled when the symbols DEBUG or CONTRACTS_FULL are defined. DEBUG won't work on release builds, and CONTRACTS_FULL will also turn on all other contracts checking, some of which you might not want to be present in release builds.