Designing for Simplified Catch Blocks

Common exception handling behavior, such as logging and replacing exceptions to hide sensitive information, typically requires multiple lines of code. Updating exception handling behavior to accommodate a change in an exception handling policy usually involves updating multiple files and lines of code. This process can be error-prone, and it is difficult to ensure that policies are updated consistently across all layers of an application.

The Exception Handling Application Block simplifies both the exception handling code and the process of updating that code. It does this by associating exception handling behavior with policy names such as "Data Access Layer Policy" and "Trust Boundary Policy." The behaviors represented by policy names are controlled externally, in the configuration file for the application. This means that a developer needs to use only two elements to write code in the catch block of an application:

• A call to the static method HandleException that passes the policy name and the exception.
• A check of the return code from the HandleException method. If it is true, the original exception should be rethrown.

Design Implications

Encapsulating exception handling logic into a single method call implies two things about the design of the Exception Handling Application Block:

• There must be API support for policy names.
• There is a dependency on the Enterprise Library Core.

The next sections describe each of these implications.

API Support for Policy Names

The HandleException method accepts as input a string that contains a policy name and the exception object. The ExceptionPolicyFactory object uses this policy name to locate the appropriate exception policy information, such as the exception handlers to be run, within the application's configuration file.

The policy name used in the code must match a policy name found in the configuration file. Instead of requiring developers to first create different policies for different exception types and then to call the correct policy based on that exception type, developers can configure policies to have different behaviors for different exception types. To support this feature, the HandleException method also accepts the original exception object as input.

Frequently, applications must propagate exceptions to callers by executing a throw statement. If the Exception Handling Application Block issued the throw statement, the stack trace would indicate that the exception occurred within the application block and not within the application code. To allow the captured stack trace information to reflect the point in the application at which the propagation occurred, the HandleException method returns a Boolean value. This indicates whether the policy for the exception type dictates that propagation should occur. It is the responsibility of the application code to check the return value and, if true, throw the original exception. The following code shows how to do this.

bool rethrow = ExceptionPolicy.HandleException(ex, "Data Access Layer Policy");
if (rethrow)
{
  throw;
}

'Usage
Dim rethrow As Boolean = ExceptionPolicy.HandleException(ex, "Data Access Layer Policy")
If (rethrow) Then
    Throw
End If

Dependency on the Enterprise Library Core

Policies are defined externally in the configuration file for the application. The Exception Handling Application Block relies on the factory design pattern for creating policy objects. Configuration data determines the types of these objects and their attributes. The factory classes use the configuration helper classes in the Enterprise Library Core to construct object instances based on configuration data. For more information, see The Enterprise Library Core.