Search code examples
.netexceptionenterprise-libraryapplication-blocks

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

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 surrounding or calling code when you change the exception handling behavior.

For example, your code will likely start to behave incorrectly when you reconfigure such that a particular exception thrown at a particular point is now swallowed instead of rethrown (there might be code after the catch block that must not be executed when the exception occurs). The same goes for all other possible changes in exception handling (e.g. replace -> rethrow, swallow -> wrap).

So, to me the bottom line is that the exception handling block solves problems that really don't exist in practice. The exception logging and notifying bit is fine, but isn't all the other stuff just a perfect example for overengineering?

Solution

  • If you use exceptions for control flow, then you would want to stay away from policy-based exception handling.

    But in the case of exceptions which you want to treat as non-recoverable (a background task failed, the socket was disconnected, the file was deleted, etc.), you may want to have configurable, policy-based exception handling.

    For example, if you are developing an API, you may want to have every function in your API throw only the standard exceptions (ArgumentException, etc.), as well as your own library-specific exception in the case of an inner non-standard exception (e.g. a MyLibraryException). In this type of case, all that matters is that something did not work correctly. You are not picking apart the exception and figuring out what went wrong. You are simply acknowledging the fact that something went wrong, and that you are supposed to do something now.

    That something should be configurable, because it doesn't really matter what you do. Display a Message Box to the user? Modal or non-modal? Log the exception? How do you want to log the exception? Call a logging web service? Append to a log file? Write to the Windows Event Log? Insert an entry into the database? Insert an entry into two databases? It doesn't really matter to the rest of your application. The choice of how to handle an exception is completely orthogonal to the rest of the application.

    (As an aside, this is not how I would approach configurable policy-based exception-handling. I would tends more towards an AOP style, such as registering an exception-logger interceptor in the container.)