Designing for Simplified Catch Blocks

Microsoft Enterprise Library 5.0

DropDown image DropDownHover image Collapse image Expand image CollapseAll image ExpandAll image Copy image CopyHover image

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 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 HandleException or Process method that passes the policy name and the exception.
  • A check of the return code from the HandleException method; if it returns true, the original exception should be re-thrown.

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 and Process methods accept as input a string that contains a policy name. The ExceptionManager 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.