Part IV in C#

Generate PDF 417 in C# Part IV

and finally blocks . In addition, the CLR will compile all the code in the catch and finally blocks including all the methods called from within those blocks . This will eliminate a bunch of potential exceptions (including FileLoadException, BadImageFormatException, InvalidProgramException, FieldAccessException, MethodAccessException, MissingFieldException, and MissingMethodException) from occurring when trying to execute error recovery code (in catch blocks) or cleanup code (in the finally block) . It will also reduce the potential for OutOfMemoryException and some other exceptions as well . I talk about CERs later in this chapter .

Depending on where the state lives, you can use transactions which ensure that all state is modified or no state is modified . If the data is in a database, for example, transactions work well . Windows also now supports transacted registry and file operations (on an NTFS volume only) and so you might be able to use this; however the .NET Framework doesn t expose this functionality directly today . You will have to P/Invoke to native code to leverage it . See the System.Transactions.TransactionScope class for more details about this . You can design your methods to be more explicit . For example, the Monitor class is typically used for taking/releasing a thread synchronization lock as follows:

public static class SomeType { private static Object s_myLockObject = new Object(); public static void SomeMethod () { Monitor.Enter(s_myLockObject); // If this throws, did the lock get taken or // not If it did, then it won't get released! try { // Do thread-safe operation here... } finally { Monitor.Exit(s_myLockObject); } } // ... }

Due to the problem shown above, the overload of Monitor s Enter method used above is now discouraged, and it is recommended that you rewrite the above code as follows:

public static class SomeType { private static Object s_myLockObject = new Object(); public static void SomeMethod () { Boolean lockTaken = false; // Assume the lock was not taken try { // This works whether an exception is thrown or not! Monitor.Enter(s_myLockObject, ref lockTaken); // Do thread-safe operation here... }

finally { // If the lock was taken, release it if (lockTaken) Monitor.Exit(s_myLockObject); } } // ... }

While the explicitness in this code is an improvement, in the case of thread synchronization locks, the recommendation now is to not use them with exception handling at all . See 29, Hybrid Thread Synchronization Constructs, for more details about this . If, in your code, you have determined that state has already been corrupted beyond repair, then you should destroy any corrupted state so that it can cause no additional harm . Then, restart your application so your state initializes itself to a good condition and hopefully, the state corruption will not happen again . Since managed state cannot leak outside of an AppDomain, you can destroy any corrupted state that lives within an AppDomain by unloading the entire AppDomain by calling AppDomain s Unload method (see 22 for details) . And, if you feel that your state is so bad that the whole process should be terminated, then you can call Environment s static FailFast method:

public static void FailFast(String message); public static void FailFast(String message, Exception exception);

This method terminates the process without running any active try/finally blocks or Finalize methods . This is good because executing more code while state is corrupted could easily make matters worse . However, FailFast will allow any CriticalFinalizerObjectderived objects, discussed in 21, Automatic Memory Management (Garbage Collection), a chance to clean up . This is usually OK because they tend to just close native resources, and Windows state is probably fine even if the CLR s state or your application s state is corrupted . The FailFast method writes the message string and optional exception (usually the exception captured in a catch block) to the Windows Application event log, produces a Windows error report, creates a memory dump of your application, and then terminates the current process . Important Most of Microsoft s FCL code does not ensure that state remains good in the case

of an unexpected exception . If your code catches an exception that passes through FCL code and then continues to use FCL objects, there is a chance that these objects will behave unpredictably . It s a shame that more FCL objects don t maintain their state better in the face of unexpected exceptions or call FailFast if their state cannot be restored .

The point of this discussion is to make you aware of the potential problems related to using the CLR s exception-handling mechanism . Most applications cannot tolerate running with a corrupted state because it leads to incorrect data and possible security holes . If you are writing an application that cannot tolerate terminating (like an operating system or database