Monday, March 30, 2009

Recommended strategy for handling exceptions in dot net applications

Purpose of this article 

  1. Take advantage of the good exception handling practices
  2. To provide a structured approach in handling exceptions


There is a significant amount of debate in my workplace about how much of exception handling is enough and what really should be the scope of exception handling. Without getting into the debate myself, I am going to present my views on the scope, benefits, drawbacks and the most appropriate way of handling exceptions in dot net projects. 


Exceptions are not expected to occur but are known to happen when either there is a flaw in the coding or the system has received data it is not equipped to handle. Professed exceptions that are raised within code due to foreseen circumstances such as, duplicate record entry, etc should not stop the program execution. The user should be displayed an appropriate warning message and allowed to take corrective action. The true exceptions should be, 

  1. Logged at the first occurrence location into a log file
  2. A new custom exception with only those exception details that may be used within the code and the exception class inheriting from ApplicationException should be created and rethrown.
  3. This custom exception should be caught and rethrown across all levels till we reach an event handling method (e.g.: catch(CustomException) { throw; }.
  4. The user should be redirected to an error page which displays some summary details of the exception and any standard message to the user that may suit the need of the application.
  5. The same error page could allow the user to bring this exception to the notice of a designated authority (maybe a web admin) via email created in a rich text environment (also allowing snapshots to be attached). This is important if the exception can keep occurring every time the user revisits the involved activity keep the user from carrying on with his / her tasks. However, this may be more useful in the case of intranet applications. Public portals could cause a deluge!


Details that should go into an Exception and its message

Typically, there are two kinds of exceptions that will occur. The first kind is thrown by the system and the second kind is thrown from the code. In the former case,, post logging, you should replace it with your own exception object (inheriting from ApplicationException class). 

In the case of your wanting to throw an exception, the message should contain the following information, 

  1. The method name which first caught / invoked the exception.
  2. The class name (whether it’s a web page or windows form or a library class) which contains the method mentioned in point 1.
  3. Some details of the cause of exception / the activity that has been affected by this exception.

 Additional information may be provided as per the application requirements. 

Proposed Framework for Exception Handling in an Application

  1. Catch and throw exceptions as proposed in the above sections
  2. Log the exception to a log file the first time it is caught
  3. Display a user expectation friendly error page when exceptions occur giving the facilities mentioned above
  4. Run a background service that periodically clears the log file entries and transfers them to a database for analysis of application state. Alternatively, you can log the exceptions to a database straight away and keep the log file as a backup plan incase the database is unresponsive.


The details mentioned so far are more with respect to dot net (c#,, applications and specific applications, especially scientific or time critical applications may require a different approach to exception handling. I am sure that there may be scenarios / options / issues that have not been mentioned explicitly in this article. Anyone contributing to this article would be appreciated. I am also more than willing to provide further information on specific questions.