Managing Exceptions in .NET

Exception and error handling techniques is always a hot topic. There are so many articles and books written on this subject. But, when you go through any of the articles you might end up with the decision that this is not what you want or this cannot be implemented in your project. In that case, what is the solution? Decide your own exception handling practices right from the beginning. Implement them and test them.

Basically, there is lot of difference between an error and an exception. As said, an exception should be a real exception. Most errors can be validated and controlled on the UI layer and need not to be carried to the business layer. Errors should be controlled and validated; they should not be converted to exceptions unless and until it is necessary to do so.

For example, suppose you have a function called GetBillCyclePeriod(Customer cust) in your business logic. The UI sends the customer object. If the function receives the customer object as null, it is an error and not an exception. People code like this:

Public DateTime[] GetBillCyclePeriod(Customer cust)
{
   if (cust == null)
   {
      throw new ArgumentNullException();
   }
}

This is very bad practice because exceptions are very costly and, if not used properly, they harm performance. In fact, the example above is an error from the UI and should be validated on the UI itself. Some examples of exceptions can be that the database server is down, network is very slow, system crashes; these really are exceptions. In the coming sections, you will see how you can deal gracefully with the exceptions.

To build a successful, bug free, and stable application, you should design the exception handling architecture and strategy in a way that will help you maintain the application and fix any bugs by providing you with detailed information. (100% bug free is not possible. The code should at least be less prone to errors and errors should not recur.) The exception handling system should be able to perform the following tasks:

1. Detect an exception.
2. Log an exception.
3. Report an exception (by means of mail or something like that).

Understanding Exceptions

The .NET framework provides a very good exception handling framework. Even if you use DLLs created in VB .NET in C# and the DLL throws an exception, the C# application block can handle that exception easily. This is possible because of CTS and CLS. I’ll not go into depth with CTS and CLS because this article is intended for advanced users who are pretty much familiar with .NET framework concepts.

As said earlier, there is a difference between an error and an exception. Trying to read a file that does not exist will throw an exception. But, this might not be exception. You can check whether the given file is present at the given location. The boundary line between exception and error can be defined by the application’s requirement. An error in one application might be considered an exception in another application.

Exception Hierarchy in .NET

All exception classes derive from the System.Exception base class. The .NET framework provides extensive classes to handle exceptions. All these classes are derived from System.Exception. Again extending the exception hierarchy, the .NET framework provides an ApplicationException base class to derive the application specific exception classes. You should always derive exception classes from the ApplicationException base class.