Exception handling is one of those things you have to learn and deal with as a .NET developer (or as a developer using many other languages and frameworks). Exception handling is a built in mechanism for detecting and handling runtime exceptions in your code. There are several things you need to keep in mind when thinking about exceptions in your application. Where do you throw your own custom exceptions? Where to you catch and log exceptions? How do you show exceptions to the end user?

The patterns and practices group have created some guidelines on how to best manage exceptions in your application, and even wrote an Exception Handling Application block. I think this block is now deprecated and have been replaced by the logging application block. Exception handling and logging tend to go hand in hand. And that's what brings me to the topic of this post; re-throwing exceptions.

I don't think I've blogged to much about my work related projects, but currently I'm working as a consultant on a project in the health care sector. The project I'm working on as a external consultant is to write a v2.0 of an internal application to manage research databases and collect electronic forms. The main goal of v2.0 is to decouple it from legacy systems in the health region so that the application can be used at other hospitals in other health regions in Norway.

Anyway, today I discovered that the way we handle exceptions in the application is a bit inconsistent so I decided to look into it. Most of the exception handling is done in the business layer where the exception is logged, before it's re-thrown (or at least that's what the developers who wrote the code thought) so that the UI can catch it and display it in a friendly manner. Most of the code looked something like this:

This is a common way to write code, and I've seen it several places. Developers thinks that this is the way to re-throw an exception. Actually it's not. When you're writing "throw ex", you're actually throwing a new exception, using "ex" as your exception object. When you throw a new exception in .NET the CLR needs to take a snapshot of the call stack and other environment variables to provide you with the information needed to debug the problem. The problem with the above example is that if some one else in a layer above you is catching the exception the stack trace will suggest that the exception occurred in ServiceLayer.DoSomething, and not in the underlying code. In some cases you actually want to hide the stack trace, and exception handling for services needs special considerations. But in most cases you actually want to re-throw the exception, to keep the stack trace correct and to save performance (taking a snapshot of the call stack and other variables are expensive).

I've created a simple example application showing the difference between throwing a new exception (as the example above) and re-throwing an exception within the catch block. The example "simulates" four layered application, with a data access layer, a business layer, a service facade and a user interface. Each layer is a simple class with one method, and the UI is the console application.

The exception occurs in the data layer when dividing by 0, and is first caught in the service layer where it's logged and re-thrown.

There are two versions of the service method, one that throws a new exception by calling "throw ex;", and one re-throwing the exception using "throw;".

The output is shown in the screenshot below. Notice how the stack trace of the first call (yellow) stops in the service layer, while the second call (red) shows the entire stack trace.