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:

• Logging an Exception
• Wrapping an Exception
• Replacing an Exception
• Propagating an Exception
• Displaying User-Friendly Messages
• Notifying the User
• Assisting Support Staff
• Shielding Exceptions at WCF Service Boundaries

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.

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.