title: Microsoft Exception Handling Block - Isn't it a perfect example for overengineering?
body: <p>Ever since Microsoft has introduced the application blocks, I've been bumping into people who use the <a href="http://msdn.microsoft.com/en-us/library/dd203116.aspx" rel="noreferrer">Exception Handling Application Block</a>. 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):</p>
  
  <blockquote>
    <p>The exception handling application block aims to centralize and make fully configurable with config files the following <a href="http://msdn.microsoft.com/en-us/library/dd203198.aspx" rel="noreferrer">key exception handling tasks</a>:</p>
    
    <ul>
    <li>Logging an Exception</li>
    <li>Replacing an Exception</li>
    <li>Wrapping an Exception</li>
    <li>Propagating an Exception</li>
    <li>etc.</li>
    </ul>
    
    <p>The library does that by having you modify your try catch blocks as follows:</p>
  
  <pre><code>try
  {
    // Run code.
  }
  catch(DataAccessException ex)
  {
      bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Policy");
      if (rethrow)
      {
          throw;
      }
  }
  </code></pre>
    
    <p>Based on what is specified in the app.config for the policy name (<a href="http://msdn.microsoft.com/en-us/library/dd139868.aspx" rel="noreferrer">see here for docs</a>), HandleException will either ...</p>
    
    <ul>
    <li>throw a completely new exception (replace the original exception)</li>
    <li>wrap the original exception in a new one and throw that</li>
    <li>swallow the exception (i.e. do nothing)</li>
    <li>have you rethrow the original exception</li>
    </ul>
    
    <p>Additionally you can also configure it to do more stuff beforehand (e.g. log the exception).</p>
  </blockquote>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>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?</p>