What Is the Exception Handling Application Block?

Enterprise Library's Exception Handling Application Block is a policy-driven system that lets an administrator determine how specific exceptions are handled in an application and allows a developer to concentrate on why and where exceptions should be handled. The block is an implementation of the best practices promoted by the Microsoft patterns & practices team. Its design allows exception policies to be defined for an application so that many different types of exceptions can be handled by different kinds of exception handlers without the need to specify these relationships through code.

Furthermore, the design provides extension points for creating new exception handlers and exception formatters that can be used by the Exception Handling Application Block. For example, if the exception handlers that ship with the block don't meet the needs for your application, you can develop a new one that can be used just as easily as the ones that ship with the block. The design for this application block allows for an extremely simple programming interface so application developers don't need to be concerned how an exception gets handled. This lets the code for an application remain unchanged even if a change is made to the way an exception is handled or exception handlers are added or removed for a particular scenario.

Relationship to the Exception Management Application Block

A previous application block existed that was named the Exception Management Application Block (EMAB). The Exception Management Application Block served two different purposes. The first was to assist developers in subscribing to the published best practices for creating their own custom application exceptions. The second was to provide a method for publishing this exception information to particular locations while allowing the application to remain agnostic as to the ultimate destination for the exception. The default location to which exceptions were published was the Windows Event Log; however, if an application needed to publish exception information to a different location, a developer could create a custom Publisher that could write to another location. The custom Publisher could be developed outside of the actual application, and the application could simply be configured to use the new publisher. In other words, an ExceptionPublisher in the Exception Management Application Block could really have been thought of as a "handler" for exceptions.

That brings us back to the Exception Handling Application Block. There were a lot of best practices that the Exception Management Application Block promoted; namely, the use of a base application exception class for deriving any custom application exceptions. This does not change with the Exception Handling Application Block, although the Exception Handling Application Block doesn't mention how to create custom application exceptions. Rather, the focus of the Exception Handling Application Block is to pick up where the handling mechanisms in the Exception Management Application Block left off. The specific responsibility for "publishing" information to an event log, file, or database is now handled primarily by the Logging and Instrumentation Application Block. The Exception Handling Application Block introduces a policy-based approach to exception handling by expanding on several of the concepts introduced in the Exception Management Application Block. Of course, there are a few caveats/differences.

• There is no longer a default Exception Handling publisher that publishes its information to the Windows Event Log. Instead, the task of persisting exception information is handled specifically by the LoggingExceptionHandler, which formats the information and hands it off to the Logging and Instrumentation Application Block to publish.

• Exception handlers can be chained together.

• The Exception Management Application Block only operated on the original exception that was passed to it by the application and it could only log this exception information. The Exception Handling Application Block allows exceptions to be changed, suppressed, and have information added to it, and it replaces most of the code typically found in an application's catch statements.

Because there are some best practices mentioned in the Exception Management Application Block that are not mentioned in Exception Handling Application Block, the best practices that are promoted by both of these blocks should be aggregated together. These blocks are both implementations of guidance that has been published by Microsoft's patterns & practices team in the Exception Management in .NET Architecture Guide.^[1] Similar to the approach in Chapter 4, I am not going to repeat all the information that can be found in that guide; I will focus on the parts of the guide that are specific to Enterprise Library's implementation of exception handling.

^[1] Found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp.

Custom Exceptions and Exception Hierarchies

Before delving into the specific design of the Exception Handling Application Block, let's focus on the part of the Exception Management Application Block that is not directly addressed by the Exception Handling Application Block: the need to have a well-thought out and designed exception hierarchy.

The Microsoft .NET common language runtime provides a means for notifying programs of exceptions in a uniform way. The guidance found in the Exception Management in .NET Architecture Guide states that all application-specific exception classes should derive from the ApplicationException class. This class derives from the base Exception class but does not provide any extended functionality. Rather, it merely serves as a base class in the Exception class hierarchy from which all custom application exceptions should be derived.

This hierarchy is important as it allows an application to benefit from the following.

• Easier development, because properties and methods can be defined on a base application exception class and inherited by derived application exception classes.

• New exception classes created after an application has been deployed can derive from an existing exception type. Existing exception handling code that catches one of the base classes of the new exception object will catch the new exception without any modifications to existing code, interpreting it as one of the object's base classes.

Figure 5.1, which is from the Exception Management in .NET Architecture Guide, depicts the hierarchy recommended by the Microsoft patterns & practices team.

Figure 5.1. ApplicationException Class Hierarchy

You should only create a new application exception class for an exception type that needs to be handled but is not already available in the application exception hierarchy or in the .NET Framework. Most application exception hierarchies are fairly flat, with groupings used for organizational purposes or to allow some set of application exceptions to inherit common properties or functionality. If it is valuable to include additional fields in the exception (e.g., machine name) that are not in the .NET ApplicationException class, then the values for these fields can be persisted in the new exception's serialized data stream by overriding an exception's GetObjectData method.

These values can then be retrieved from the SerializationInfo object in the constructor of the custom exception object by using one of the Get methods of the SerializationInfo object (such as the GetString method). This is necessary, because if the exception is to be marshaled across remoting boundaries it must be serializable; therefore, the additional fields must be added to the serialized data stream. Although it doesn't add other fields to the serialized data stream, the WrapperException that is shown later in this chapter (see Listing 5.11) highlights the methods that need to be created to provide this capability.

The BaseApplicationException class that existed in the Exception Management Application Block made it easy for application developers to subscribe to the best practice of handling exceptions with a single base application exception class that derives from ApplicationException. This class served as the base class for all application exception classes. It contained fields that captured specific information like the date and time an exception occurred, the machine name on which an exception occurred, and so on. Rather than requiring every custom application exception to include these fields, these common exception details were encapsulated in this single base class and made available to any custom application exception class through inheritance.

The Exception Management Application Block provided the BaseApplicationException, but this isn't included in Enterprise Library's Exception Handling Application Block. If it is important to capture the exception information in the actual exception object itself, then it still makes sense to use a class like BaseApplicationException in an application. The Exception Handling Application Block provides an alternate method for obtaining the exception information that the BaseApplicationException encapsulated; however, it does not require the exception information to be added to the actual exception object. This construct is known as an ExceptionFormatter. (The ExceptionFormatter as well as how to extend the Exception Handling Application Block to use a new, custom ExceptionFormatter is covered with the LoggingExceptionHandler later in this chapter.)

Whether you use ExceptionFormatters explicitly or leverage a base application exception class, it is important that an application's exception hierarchy has been designed. It is this hierarchy that guides the behavior of how exceptions are handled both with the Exception Handling Application Block and the .NET runtime. Once this hierarchy has been designed, you can think more about how exceptions should be handled in an application. This is where the new Exception Handling Application Block really provides the most benefit.