4.9. Exception Handling

Exception handling has been improved in .NET 4.0 with the introduction of the System.Runtime.ExceptionServices namespace, which contains classes for advanced exception handling.

4.9.1. CorruptedStateExceptions

Many developers have written code such as the following:

try
{
// do something that may fail
}
catch(System.Exception e)
{
...
}

(OK, I might have done this, too.) This is almost always a very naughty way to write code because all exceptions will be hidden. Hiding exceptions you don't know about is rarely a good thing, and if you do know about them, you should inevitably be handling them in a better way. Additionally, there are some exceptions that should never be caught (even by lazy developers), such as lowdown beardy stuff like access violations and calls to illegal instructions. These exceptions are potentially so dangerous that it's best to just shut down the application as quickly as possible before it can do any further damage.

So, in .NET 4.0, corrupted state exceptions will never be caught, even if you specify a try...catch block. However, if you do want to enable catching of corrupted state exceptions application-wide (e.g., to route them to an error-logging class), you can add the following setting in your application's configuration file:

LegacyCorruptedStateExceptionsPolicy=true

This behavior can also be enabled on individual methods with the following attribute:

[HandleProcessCorruptedStateExceptions]