Alex Rivera | Logout

Microsoft Exception Handling Block - Isn't it a perfect example for overengineering?

Asked 2009-01-03T02:11:36.463
19

Ever since Microsoft has introduced the application blocks, I've been bumping into people who use the Exception Handling Application Block. I've recently had a closer look myself and would summarize the basic functionality as follows (skip the following block if you already know what it does):

The exception handling application block aims to centralize and make fully configurable with config files the following key exception handling tasks:

  • Logging an Exception
  • Replacing an Exception
  • Wrapping an Exception
  • Propagating an Exception
  • etc.

The library does that by having you modify your try catch blocks as follows:

try
{
  // Run code.
}
catch(DataAccessException ex)
{
    bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
    if (rethrow)
    {
        throw;
    }
}

Based on what is specified in the app.config for the policy name (see here for docs), HandleException will either ...

  • throw a completely new exception (replace the original exception)
  • wrap the original exception in a new one and throw that
  • swallow the exception (i.e. do nothing)
  • have you rethrow the original exception

Additionally you can also configure it to do more stuff beforehand (e.g. log the exception).

Now here's my problem: I completely fail to see how it can be beneficial to make it configurable whether an exception is replaced, wrapped, swallowed or rethrown. In my experience, this decision must be made at the time you write the code because you'll typically have to change the surroun

.net exception enterprise-library application-blocks
Edit
Report

1 Answer

4

I have to agree with the statement that "the exception handling block solves problems that really don't exist in practice." I've used the block since its release and I rarely feel like I'm actually gaining much by using it. Well, perhaps a bit of a headache. :)

Before starting, I will admit that I do like the Exception Shielding at WCF Service Boundaries functionality. However, that was added fairly recently, involves no coding -- only attributes and configuration, and is not how the block is usually sold. This is how Microsoft shows it at http://msdn.microsoft.com/en-us/library/cc309250.aspx

alt text

To my eyes the above is flow control. 

try
{
  // Run code.
}
catch(DataAccessException ex)
{
    bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
    if (rethrow)
    {
        throw;
    }
}

When you combine the flow control aspect with the code above you are definitely not making wrong code look wrong. (Never mind that the if (rethrow) construct does not offer very much abstraction.) This can make maintenance more difficult for developers unfamiliar with the policy definitions. If the postHandlingAction in the configuration file is changed (it will probably happen at some point) you will probably find the application behaving in unexpected ways that have never been tested.

Perhaps I wouldn't find it as objectionable if the block did not handle flow control but simply allowed you to chain handlers together.

But perhaps not. I don't actually recall e

answered 2010-01-21T08:36:02.650

Your Answer