We need a custom strategy for collecting unhandled application exceptions. What are our options?

Question

"Unhandled exception" term

In .NET Framework, unhandled exceptions are the exceptions which were not handled by the application itself, and result in a crash. In a case of a desktop application, it means that a window similar to this one is displayed:

For a web application, it mostly means an HTTP 500.

Under unhandled exceptions, I also include ones which are "handled globally", i.e., in a case of a desktop applications, the global handling which consists of displaying a custom window instead of the Windows default one.

Context

When I work as a freelancer, I use my own in-house solution to gather unhandled exceptions from different sources (web apps and desktop apps). The gathered results are then displayed on a monitoring panel in real time as well as collected for future analysis (to be linked with a bug tracking software, etc.)

Currently, I work in a company where I wouldn't be able to use my in-house solution to collect the exceptions (one of the reasons being that they won't accept to send all the exception messages to my servers).

This company doesn't have any precise strategy for collecting unhandled exceptions. The only solution which was used before is both rudimentary and out of question: it consists of sending every exception by e-mail.

This means that for the new product I'm working on, we should develop a custom strategy for collecting unhandled exceptions.

Question

I can always do by hand the part which will save the exceptions to the database or a log and the part which will load them from the database, a log or Windows Events.

I would like to avoid reinventing the wheel and use something which is already commonly used.

What are my choices? How are unhandled exceptions usually collected and processed later?

By the way:

• Are there any libraries which help collecting those exceptions?
• Are there any software products which help analyzing those exceptions?

Answer 1

In short: It will depend on .NET Framework version, as it might be handled differently in .NET 4.0 than in 2.0.

A general rule of thumb is, when a runtime error occurs ( Runtime Error Yellow Screen of Death - YSOD) on a web application in production it is important to notify a developer and to log the error so that it may be diagnosed at a later point in time.

There are several resources on this topic. For .NET 2.0 applications you may look at overview of a post how ASP.NET processes runtime errors and looks at one way to have custom code execute whenever an unhandled exception bubbles up to the ASP.NET runtime.

Starting with .NET 4.0 developers get more flexibility by Asynchronous Programming Model (APM pattern). More details are posted here.

Prior to the .NET Framework 2.0, unhandled exceptions were largely ignored by the runtime. For example, if a work item queued to the ThreadPool threw an exception that went unhandled by that work item, the ThreadPool would eat that exception and continue on its merry way. Similarly, if a finalizer running on the finalizer thread threw an exception, the system would eat the exception and continue on executing other finalizers.

There are different flavor of User friendly Exception Handling dialog strategies that you might look for windows forms applications.

In conclusion, there are some options depending on the Framework version that .NET application currently runs on.

Answer 2

In previous dev shop we used Microsoft's Exception Application Block - a .NET extension - to capture exceptions into a database and notify the developer. We had a home-made web front end to access (no pun intended) that data.

The Application Block is designed to be highly configurable.

A dated blurb from 4GuysFromRolla.com