Recipe7.10.Preventing Unhandled Exceptions

Recipe 7.10. Preventing Unhandled Exceptions

Problem

You need to make absolutely sure that every exception thrown by your application is handled and that no exception is bubbled up past the outermost exception handler. Hackers often use these types of exceptions to aid in their analysis of the vulnerabilities of a web application for instance.

Solution

Place try-catch or try-catch-finally blocks in strategic places in your application. In addition, use the exception event handler as a final line of defense against unhandled exceptions.

Discussion

If an exception occurs and is not handled, it will cause your application to shut down prematurely. This can leave data in an unstable state, possibly requiring manual interventionmeaning that you could be spending a long night cleaning up the data by hand. To minimize the damage, you can place exception handlers in strategic locations throughout your code.

The most obvious location to place exception-handling code is inside of the Main method. The Main method is the entry point to executables (files with an .exe extension). Therefore, if any exceptions occur inside your executable, the CLR starts looking for an exception handler, starting at the location where the exception occurred. If none is found, the CLR walks the stack until one is found; each method on the stack is examined in turn to determine whether an exception handler exists. If no exception handlers are found in the final method in the stack, the exception is considered unhandled and the application is terminated. In an executable, this final method is the Main method.

In addition to or in place of using try-catch or try-catch-finally blocks at the entry point of your application, you can use the exception event handler to capture unhandled exceptions. Note that Windows Forms applications provide their own unhandled exception trap around exception handlers. To see how to deal with this in a Win-Forms application, review Recipe 7.20. There are two steps to setting up an exception event handler. The first is to create the actual event handler. This is done as follows:

 static void LastChanceHandler(object sender, UnhandledExceptionEventArgs args) {     try     {         Exception e = (Exception) args.ExceptionObject;                  Console.WriteLine("Unhandled exception == " + e.ToString( ));         if (args.IsTerminating)         {             Console.WriteLine("The application is terminating");         }         else         {             Console.WriteLine("The application is not terminating");         }     }     catch(Exception e)     {         Console.WriteLine("Unhandled exception in unhandled exception handler == " +                            e.ToString( ));     }     finally     {         // Add other exception logging or cleanup code here.     } }

Next, you should add code to your application to wire up this event handler. The code to wire up the event handler should be executed as close to the start of the application as possible. For example, by placing this code in the Main method:

 public static void Main( ) {     appdomain.CurrentDomain.UnhandledException +=         new UnhandledExceptionEventHandler(LastChanceHandler);          //… }

you are assured of being able to clean up after any unhandled exception.

The exception event handler takes two parameters. The first is the sender object, which is the appdomain object that threw the exception. The second argument is an UnhandledExceptionEventArgs object. This object contains all the relevant information on the unhandled exception. Using this object, you can obtain the actual exception object that was thrown as well as a Boolean flag that indicates whether the application will terminate.

Exception event handlers are a great help when used in multithreaded code. In the 1.x versions of the Framework, if an unhandled exception were thrown in a thread other than the main thread, that thread would abort. However, only the worker thread, and not the application as a whole, would terminate. But you were not clearly notified when the CLR aborted this thread, which could cause some interesting debugging problems. In Version 2.0 of the Framework, any unhandled exception will now propagate and cause the application to terminate. However, when an exception event handler is used, you can be notified of any unhandled exceptions that occur in any worker thread and that cause it to abort.

The exception event handler captures unhandled exceptions for only the primary application domain. Any application domains created from the primary application domain do not fire this event for unhandled exceptions. These secondary appdomains must be registered with as well for the UnhandledException event individually to receive their exception events. Note that if the exception is thrown on the main thread, the system will bring up an error dialog before running the exception event handler.