Lately, I've been thinking about exceptions vs. error codes. As usual, Joel On Software has a couple of well thought out posts on the topic. The first post makes the point that exceptions "create too many possible exit points for a function". The second post, Making Wrong Code Look Wrong makes some very good points on exception handling as well as other topics. In the same way that compile time errors are better than runtime errors, it is better to find errors in code simply by reading the code than by being forced to run or debug the code. That seems like a pretty straight forward statement to me but I'm wondering if people actually agree with it -- what with the popularity of various frameworks where everything is hung together with configuration files.
Those two ideas -- exceptions as flow control and making code look wrong -- led me to think about why I really, really dislike Microsoft's Enterprise Library Exception Handling Block: it combines the worst parts of both.
Consider the following:
C#:
-
try
-
{
-
DoSomething();
-
}
-
catch (Exception e)
-
{
-
bool rethrow =
-
ExceptionManager.HandleException(e,
-
"MySpecialPolicy");
-
-
if (rethrow)
-
{
-
throw;
-
}
-
}
My objection: you have no idea what the exception handler does!
Since you can't tell what will happen at this one point, you can't mentally trace the program flow to see if it's logically sound. This makes development, tracking down bugs, and overall maintenance difficult.
"Wait, wait, wait", you say. "You can create meaningful policy names to avoid this kind of confusion". Yes, you can change the policy name to something more meaningful like "BusinessLayerMustRethrowPolicy" so you can understand the intent of the code -- which is a good thing. However, you still have no idea of the actual behavior at run time since the configuration could be set to not rethrow (for some reason). Plus, if you are making your exception handling configuration based, then you are implicitly saying that you allow the configuration to be changed to another setting (e.g. not rethrow an exception). Isn't that the point of putting things in configuration? To allow behavior to be changed without changing the code.
Since throwing an exception changes the flow of the program, if you modify the Exception Handling Block configuration (behavior) then you are actually creating a new execution path. Does that mean the program should run "properly" for all possible settings of the configuration? (Not likely!) Do you then have to test all of those possible code paths?
Maybe you could implement a policy of no configuration changes without a full test cycle but then how is that much different than performing a code change? You do skip the issue of introducing a new coding bug
and you avoid a build but you still need to create some sort of deployment package and go through a release cycle (which is the most expensive part in this lifecycle). Plus there is always the chance of the configuration becoming incorrect "by accident" and the new execution path may introduce some undesirable behavior. e.g. maybe database changes are committed because, even though an exception occurred, the policy said to not throw an exception and the calling code assumed that all errors would be reported as exceptions.
Other objections to the Exception Handling Block:
- As a framework, the "if rethrow" construct doesn't really offer a lot of abstraction; you still need to pepper your code with "if rethrow" code in every catch block.
- If you try to use the logging block to log an exception, every log entry for that handler shares all of the same basic log entry information (e.g. event ID). This can be restricting if you need that kind of control.
In general, I avoid the Exception Handling Application Block because it obfuscates the functioning of the program which makes the program harder to understand and maintain. To me this outweighs any functionality provided by the block.
Categories: .Net
1 Comment »
