Exception Handling Best Practices

Anyone who has been a programmer in his life, knows about exceptions and also knows that there is no exception to having Exceptions in one's code! Fresh programmers however often overlook the importance of having exception management framework in their applications. A proper, well-defined exception handling framework along with a logging framework is absolutely essential for making sure that your program or application does not spring surprises on you later!

So, what are the best ways of handling Exceptions in the code? What should one do and what should one not do as regards Exceptions?

1. Catch Exceptions the right way

In C# or in Java, the way to handle exceptions is to put the code that could generate the exception into a try..catch..finally block. If there are multiple catch blocks, make sure that these are ordered from the most specific type to the most generic type. This ensures that the catch block for the most specific type of exception is considered first for any given exception, thus guaranteeing a specific treatment to that exception if required.

2. Catch Exceptions only if you know what to do with them!

Most of us, most of the times, blindly write the try..catch blocks, just because the IDE makes us do it. Because of that we end up having catch blocks as below:
catch(Exception exp){ throw exp;}
Now, the thing to note here is that you have not done anything really by catching that exception. It has just been rethrown from the catch block. If you find such lines in your code, the first thing you should be doing is simply removing those catch blocks. Instead, let these exceptions propagate further to the caller methods - which perhaps know better what to do with them.

Catch an exception only if:

a. You want to log that exception - The exception message and the stack trace when logged give a good picture to the developer as to what has gone wrong.
b. You want to write some clean-up code - In this case you can rethrow the same exception if no extra information is needed
c. You want to write some code to recover from the exception
d. You want to add some relevant information to the exception - This is particularly necessary in multi-tier applications or end-user applications where some nice user-friendly message has to be shown to the user. As an exception is propagated up the call-stack, often the information associated with it becomes less relevant. In such cases, wrap the actual exception in a custom, application specific exception. Remember to store the actual exception in the "InnerException" property of .NET Exception class (This is possible in Java too). This ensures that the actual exception is never lost and can always be retrieved if required.

3. Use Exceptions sparingly

Catching and Throwing of Exceptions is performance intensive. Never use exceptions to control the normal flow of operations in the code.

4. Use Custom Exceptions

As mentioned in point 2 d., one of things that one can do after catching an exception is to wrap it up in a more understandable exception with some extra information. This is where we need custom exception classes, exceptions that are specific to your application. In .NET, this can be done by extending the "ApplicationException" class. The entire hierarchy of the application exceptions can be bundled into one single assembly so that it can be referenced everywhere in your application.

A comprehensive article on Exception Management in .NET at http://msdn2.microsoft.com/en-us/library/ms954599.aspx