I have been using Microsoft Enterprise Library (EntLib) since day one of the public release and I believe that I will blog a bit about it in some coming posts and I'll start today with a brief overview of the Exception Handling Application Block. I've also used the old Exception Application Block that I think was one of the first code blocks that the PAG-team released. My experiences of that block is very good. It has given the project a very solid solution for our exception handling and logging. After a while the PAG-team released more blocks and one that made the picture a little bit unclear was the release of the logging application block. It overlapped in functionality with the logging part of the exception block.

With the release of the EntLib they got a more consistent view of the different blocks. It's clearer what each block do and don't do. In EntLib the exception block doesn't do any logging, that is what the logging application block does. The exception block is totally focused on giving you a structured and flexible way to deal with exceptions.

The idea is that you should define policies and this policies has the configuration of how an exception shall be handled. Each policy can handle different types of exceptions in different ways. So far I have treated each exception type in the same way in a specific policy, but it aren't hard to figure some cases where you would like to do different things for different exceptions.

For the policy you can define which handlers should be invoked. The block has three built in handlers and it is easy to wrap up your own handlers (I will probably write a separate post about this). The three built in handlers are:

All the work with the configuration is easily done with the help of the Enterprise Library Configuration application. So what does the code look like?

 

 

I guess that I only will have to explain what the boolean variable is doing and controlling if I rethrow the exception or not. When you configure you policy you also have the power to say what shall happen after the handlers have done their stuff. It has three possible values: None, NotifyRethrow and ThrowNewException. For example you could have a policy called "Handle and resume" that has the PostHandlingAction set to None and therefore shouldn't throw any exception (at least not of some types). And then you could have another policy called "Propagate Policy" that for example logs the exception and then rethrows it (PostHandlingAction=NotifyRethrow). Your code should probably take the advice from the configuration.

The biggest disadvantage of the design of the new exception handling block is that it depends on that you have configured all policies that you use in code. This could be a problem if you develop generic components or smaller frameworks because you are suddenly in the situation where you have to trust the user (=the developer) of your components to define all policies that you use in your code or else your code will break. This requires that you document it very well and probably also make some recommended configuration for the components that you deliver as part of the component. Generally the documentation of the entire EntLib has a lot more to wish and I hope that they start publishing better examples and documentation (hopefully before their next release, that will target .NET Framework 2.0).