Bubble, Bubble Toil and Trouble: Throwing and Catching

Exception handling is a bit of an art. There is a fine line between over-handling exceptions and under-handling exceptions. You can over-handle exceptions to the point where every error that your application generates is intercepted in poorly designed exception handlers that hide problems and do not correct the errors.

Then there is the other end of the spectrum: under-handling exceptions to the degree that your application becomes a continual experience of those yellow and white NET exception Web pages that frustrate and hinder the user, keeping him from accomplishing the work at hand.

With this in mind, here are some tips that you can use as a guideline to programming with exceptions.

1. Do not hide problems by hiding exceptions.

Let's say that your development team decides that it will present to end users only the exceptions that are show stoppers. For example, your team decides that if you are doing a data submission of non-time sensitive data, and if the datasource to which your application is submitting is not available, you will send the data to a temporary submission queue. Thus, your application logic looks something like the comments shown in Listing 6.

Listing 6: A example of catching an exception and hiding the problem.

//Open the data source.
//Catch a "no connection" exception,
// and send the data to the temporary submission queue

//Otherwise, submit the data now

//Go about your business.

For the most part, the instruction set described in Listing 6 makes good sense. There is no need to tell the end user that her data could not be submitted immediately and that it is in queue. Nothing panics an end user more than encountering application exceptions that she can do nothing about.

Yet, there is a problem because there was a problem! The datasource connection was not available. Granted, it is not a show stopper problem. You have a plan in place to handle the exception. However, your application made no record that the exception occurred! Suppose the connection was a continuous problem, being off-line more than on-line. You would have no way of knowing. The way that you handled the exception offers no way to know that a problem exists.

Your application should have logged the exception as shown in Listing 7.

Listing 7: An example of catching an exception and exposing the problem.

//Open the data source.
//Catch a "no connection" exception, 
// send the data to the temporary submission queue,
// write the exception occurrence to a log file.

//Otherwise, submit the data now

//Go about your business.

Many tools out there allow you to log exceptions. .NET has a set of classes that allows you to write to the Event Log on the computer upon which your application is running. Also, there is a third party, Open Source tool, log4net, which allows you to log exceptions in a very elegant, robust way.

2. Design an exception architecture for your application.

It is not a good practice for individual developers in an enterprise environment to handle exceptions in a manner inconsistent with the rest of the team. In terms of exception handling, a good practice is for the team to decide:

• which category of exceptions get handled "on the spot," and
• which category of exceptions are left unhandled and allowed to bubble up to a higher logical level in the application

In most cases, the latter is a central exception handling area of the application.

Creating an application without an exception handling architecture in place leads to code that is, at best, sporadically buggy; and in the worst case, a nightmare to maintain.

3. If you don't know what to do with it, bubble it up.

As mentioned earlier, you do not need to handle all exceptions at the method level. In fact, a good rule of thumb is that, when you encounter an error and you don't know what to do with it, let it go by not catching it at all. Or re-throw it with the throw keyword. Catching exceptions just to catch exceptions is a waste of time.

4. If you throw an exception, make sure that you add value.

It is not unusual for programmers that have recently learned how to create custom exception classes to use them all the time, to create a "brand" identity for his application. For example, a programmer might want to catch InvalidOperationException and re-throw them as MyCustomGeneralSystemException. The question to ask here is does such customization add value to the application or component that is catching the exception at a higher level?

If the developer can make a compelling case for hiding the original exception and providing a more general reinterpretation of the exception, then by all means throw the custom error. Otherwise, if using a custom exception type adds no additional value over the more typical exceptions, such customization should be avoided. If you do create custom exception types, it is a good idea to pass the exception to which are you are adding value as a inner exception of your custom exception type.

5. Have a plan for all unhandled exceptions.

At the application level, no exception should be left unhandled. There should always be an exception handler of last resort. In ASP.NET, you can add a page level handler for all unhandled exceptions by overriding the a page's OnError event handler. You can override a page's OnError event handler by adding the following code to your page:

protected override void OnError(EventArgs e)
{
     base.OnError (e);
}

If you want handle unhandled exceptions at the application level, you add code to Application_Error event handler in the Global.asax.cs file.

An Exceptional Conclusion

Exception handling is a bit of an art that takes time and practice to master. Nobody gets it all at once. And, as with any programming activity, the more you do it, the better you get. You will find that, through trial and error, you will develop a technique that makes you and your team's applications reliable to use and easy to maintain.

Additional resources:

• Jeffery Richter's Web Cast on Exceptions
• Best Practices in Exception Handling
• Microsoft's Overview of Exceptions

Download the code used in this article here.