It's a fact of life that all applications have bugs- even after strenuous bench testing, automated testing, and piles and piles of test plans. When you release software into the wild, something is going to go wrong, somewhere. So it is nice to have an underlying architecture in your program so that when something does go horribly, unavoidably wrong, there is at least some record of what happened - so you can start tracking down and reproducing it. Today we are going to talk about an extremely simple way to do just that in C#.

Generally, since we are in the managed world of .NET and C#, when something horrible goes wrong with your program, it will eventually manifest itself as an unhandled exception - and then the app will crash and burn. Now, I suppose you could try and surround all your code with generic try-catch statements, but (I'm hoping) we all know that that is just a horrible idea, from performance, maintenance, and code readability perspectives. Fortunately, there is a better way to implement that idea in .NET - the UnhandledException event.

The UnhandledException is an event on the AppDomain class. An AppDomain is, in very simplistic terms, the execution environment for your code. We are going to assume today that there is only one AppDomain, and we aren't going to worry about it any more than that. Talking about AppDomains could probably take an entire tutorial in and of itself. But anyway, we have this event - what does it do and how do we attach to it?

What it does is pretty simple - the event is fired every time there is an unhandled exception that propagates all the way to the top of your application. Now, if there was nothing attached to the event, the app would show one of those classic "this app has encountered a problem and needs to close" dialogs, and down your app would go. But once you attach to this event, you have a chance to do something.

How to attach to the event is a little weird - but only in that you may have never added code to this part of a C# app before - especially if what you mostly work with are GUI apps. We need to add a line to the Main method (by default in the "Program.cs" file in a new Windows Application):


That is the content of a default "Program.cs" file for a new Visual Studio Windows Application called "MyApp" - with one difference. The line of code AppDomain.CurrentDomain.Unhandled... is what I added in order to attach to the UnhandledException event of my AppDomain. Of course, here it is referencing a function that does not yet exist (CurrentDomain_UnhandledException) - but we will get to that next.

Ok, lets write that method:


And there you go - now your unhandled exceptions are being shown in a nice happy dialog! Of course, you could do other things here - like log the exception, or try and soften the blow of the crash by saving whatever program state you can. You can't, however, actually keep the program from crashing - there is no way to "catch" the exception at this point and let the app keep on running.

But wait, theres more! As I stated before, with the UnhandledException event on AppDomain, any exception in the current AppDomain will trigger that event. This includes not only the main application thread (the UI thread), but any other threads as well. And, as I just mentioned, there is no way to "recover" once you hit that point. However, there is actually a different way to handle unhandled exceptions on the Application thread (i.e., the thread that is handling your UI - forms, painting/ user input, etc..). This is through the ThreadException event on Application. To do this, we add another line to the main method:


And we define the function Application_ThreadException:


With this method hooked to the Application.ThreadException, unhandled exceptions on the main application thread will not hit the UnhandledException event on the AppDomain - and the app will no longer terminate by default. As you can see in this method, we show a dialog asking if the user wants to continue or not - and if they choose abort, we close the app. Otherwise, we just let the app continue on.

Here is what the file "Program.cs" looks like now:


In any decent sized application, the code in either of these two methods would probably be much more complicated - logging much more state information, trying to determine if the app could continue at all, so on and so forth. But hopefully this gives you an idea of where to put that sort of logic in a C# application. As always, if you have questions, please feel free to leave them in the comments.