Share via

When Should I Use the Exception Handling Application Block?

  • Article

The Exception Handling Application Block is best used in situations that require uniform and flexible procedures for handling exceptions. For example, you might want consistent exception handling procedures for all components in a particular tier of an application's architecture. In addition, because of changing security or other operational issues, you might want the ability to change policies as needed, without requiring changes to the application source code. The Exception Handling Application Block, in conjunction with the Enterprise Library configuration tools, lets you accomplish both tasks.

For example, you could use the configuration tools to define a policy that uses handlers to replace exceptions that contain sensitive information with versions that do not include that information. The block then implements this policy across the components that contain code that specifies this policy should be used.

The Exception Handling Application Block is not limited to cross-tier applications. It can also be used within a particular application. For example, you can define policies that log exception information or display exception information to the user.

In either case, policies are configured without changing the application's code. This makes them easy to maintain or change when new situations occur. Note that, in all cases, you should use the block to perform only those tasks that are specific to exception handling and that do not intersect with the application's business logic. For example, you can remove the handlers that log an exception or wrap one exception in another without affecting such basic capabilities as updating a customer database.

Scenarios for the Exception Handling Block

The Exception Handling Application Block is designed to address the most common tasks developers face when they write applications that use exception handling. These tasks are arranged according to scenarios. Each scenario gives an example of a real-world situation, discusses the exception handling functions the situation requires, and shows the code that accomplishes the task.

The goal of arranging these tasks according to scenarios is to give the code some context. Instead of displaying an isolated group of methods, with no sense of where they can best be used, scenarios provide a setting for the code and describe situations that are familiar to many developers whose applications must handle exceptions.

The scenarios are the following:

Benefits of the Exception Handling Application Block

The Exception Handling Application Block provides a wide range of benefits for creating consistent and reusable exception handling policies that implement common patterns. The following list summarizes these benefits:

  • It supports exception handling in all architectural layers of an application and is not limited to service interface boundaries.
  • It allows exception handling policies to be defined and maintained at the administrative level so that policy makers, who might be system administrators as well as developers, can define how to handle exceptions. They can maintain and modify the rules that govern exception handling without changing the block's code.
  • It provides commonly used exception handling functions, such as the ability to log exception information, the ability to hide sensitive information by replacing the original exception with another exception, and the ability to maintain contextual information for an exception by wrapping the original exception inside another exception. These functions are encapsulated in .NET classes named exception handlers.
  • It can combine exception handlers to produce the desired response to an exception, such as logging exception information followed by replacing the original exception with another.
  • It lets developers create their own exception handlers.
  • It invokes exception handlers in a consistent manner. This means that the handlers can be used in multiple places within and across applications.

Limitations of the Exception Handling Application Block

The Exception Handling Application Block is a complement to exception handling recovery code; it is not a replacement for it. If exceptions occur because of truly unusual circumstances, it can be impossible for an application to recover gracefully and finish the unit of work it has started. However, it is sometimes possible to recover. An example is an exception that occurs because a file is locked. The recovery code might direct the application to retry the file after waiting for some period of time.

In such cases, exception handling recovery code should be implemented within the application code; it should not be implemented as a handler used by the Exception Handling Application Block. This is because it requires access to local variables, parameters, and other contextual data. This data is out of scope and inaccessible to handlers run by the Exception Handling Application Block.