IHateSpaghetti {code}

Handling Corrupted State Exceptions is not supported by default by CLR 4.0

In the February MSDN Magazine there's a very interesting article about CSE and what is changed in CLR 4.0.

It seems that the code below would wrap corrupted state exceptions thrown by the OS (such as Access Violation) and thus leaving the application non stable state when you not fixing the CSE.

   1: public void SomeFunction()

   2: {

   3:     try

   4:     {

   5:         //Do something

   6:     }

   7:     catch(Exception ex)

   8:     {

   9:         throw WrapException(ex);

  10:     }

  11: }

So they CLR guys made some changes and thus no more CSE exception will be thrown. However, if you do have support for CSE you will have to add to do the following changes:

• If you want to recompile your code created in the Microsoft .NET Framework 3.5 and run it in the .NET Framework 4.0 without having to update the source, you can add an entry in your application configuration file: legacyCorruptedState­­ExceptionsPolicy=true.
• Assemblies compiled against the .NET Framework 3.5 or an earlier version of the runtime will be able to process corrupted state exceptions (in other words, maintain the old behavior) when running on the .NET Framework 4.0.

Or, recompile with System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions attribute as following:

   1: using System.Runtime.ExceptionServices;

   2:  

   3: [HandleProcessCorruptedExceptions]

   4: public void SomeFuntion()

   5: {

   6:     try

   7:     {

   8:         //DO something

   9:     }

  10:     catch(Exception ex)

  11:     {

  12:         //Handle CSE

  13:     }

  14: }

Note the plural suffix – HandleProcessCorruptedStateExceptions – you need to be careful from CSE thrown down the stack, if you can handle a particular CSE it doesn't mean that you know or should handle or the other – so be careful !

Read the full article