How to Handle .NET Unhandled Exceptions Gracefully

I know there were already lots of discussions about this topic, but as a .NET developer and support engineer, I really want to share some experience so that beginners can start easily.

We should really pay attention to unhandled exceptions in our .NET applications because they are unhandled. This is a silly statement but we must start from it.

Do you know that Java methods expose its exception list? Every exceptions a method may throw are listed in the method signature (correct me if I am wrong as I am not a Java expert). But why C# does not have that? OK, again that’s another story to discuss, and my point is that usually you cannot foresee all exceptions that may happen in your application, so generally speaking you cannot catch them all in your source code, and claim that “it is unhandled-exceptions-free”.

Don’t tell me that you can use

 try {}
catch (Exception ex) {}

to handle all exceptions. You cannot actually (and it is highly not recommended). Please go ahead and catch only specific exceptions you are interested in, and leave the rest alone to a global place.

WinForms Global Place to Catch Them ALL

OK, .NET runtime provides a few places to capture unhandled exceptions. They are,

 Application.ThreadExceptionHandler
AppDomain.CurrentDomain.UnhandledException

I really love the article written by Jeff here, but I simply use another implementation by Mauro which I used in Code Beautifier Collection project (that library was written in Delphi for .NET but can be used for other .NET languages, and I did provide a modified version for CBC).

ASP.NET Global Place to Catch Them All

Microsoft suggests you follow this KB article(911816) to implement a capture module for ASP.NET 2.0. But in fact, slightly modifying a few lines you can make it work for ASP.NET 1.1, too (simply replace webengine.dll with mscorlib.dll or another).

You may read this amazing post for reference.

Why Catch Them ALL

I hope you are not too excited to see the above techniques work in your application, because that’s only the start.

Do you know where to move on? Personally I recommend you have an analysis on the captured exceptions to see if they reveal programming flaws or other useful information. The simplest example is,

• If you have a lot of NullReferenceException logged, sure that you should perform a source code review on the problematic methods in stack trace. What references did you not check against null?

As the developer of such an application and with source code at hand, I think you can locate the root causes within a few minutes and have them fixed within a day. Gradually you will notice what exceptions were ignored when you were coding.

Cool Things

Well, once you are able to capture unhandled exceptions, either during development or on your customers’ computer, you have a chance to apply the following cool tips,

• Send a mail to your mail box so that you can have a check immediately.
• Provide your customers a friendly dialog to report the issue.
• Whatever else you can think of.

Isn’t it a wonder if you make good use of this feature provided by the framework?

Comments

• Anonymous
  April 27, 2009
  Thanks for sharing. There is the interesting new feature in .net 4.0 that really prevents you from handling fatal exceptions, which is also a great feature

• Anonymous
  April 29, 2009
  .NET C# COM Object for Use In JavaScript / HTML, Including Event Handling Show me the memory: Tool for