This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
|The latest Enterprise Library information can be found at the Enterprise Library site.|
This topic describes the most common situations that developers must address when handling exceptions. Each scenario explains the task, describes a real-world situation where such a task might occur, and includes code that demonstrates how to use the Exception Handling Application Block to complete the task. The scenarios are the following:
- Logging an Exception. This scenario demonstrates how to use the logging handler to collect exception information, format it, and send it to the Logging Application Block.
- Replacing an Exception. This scenario demonstrates how to use the replace handler to create a new exception of a defined type that replaces the original exception.
- Wrapping an Exception. This scenario demonstrates how to use the wrap handler to create a new exception of a defined type that wraps the original exception with another exception that is more relevant.
- Propagating an Exception. This scenario demonstrates how to propagate an exception in its original state after running a chain of exception handlers.
- Displaying User-Friendly Messages. This scenario demonstrates how to either replace or wrap an exception with one that provides support or instructional information for the user.
- Notifying the User. This scenario demonstrates methods for letting a user know that an error has occurred.
- Assisting Support Staff. This scenario demonstrates how support staff can match a user's error message with the detailed information that is stored in the exception log.
In addition, this section contains the topic Shielding Exceptions at WCF Service Boundaries, which describes how unknown exceptions occurring in Windows Communication Foundation (WCF) services should not be sent to the client application, in order to prevent details of the service implementation from escaping the secure boundary of the service.
|If you use the Unity Integration approach to create instances of objects from the Exception Handling Application Block, you must use the non-static façade named ExceptionManager. This class exposes the same API as the ExceptionPolicy class static façade. For more information about using the Unity Application Block to create and inject instances of Enterprise Library objects, see Creating Objects Using the Unity Application Block.|
Exceptions can occur when you use the Exception Handling Application Block for exception handling. These exceptions are often caused by application code specifying an exception handling policy that is not part of the application configuration, or by faulty code within a custom exception handler. Exceptions also occur when the configuration information is not valid (for example, it does not contain valid XML). Because the exception may contain sensitive information, the application block does not return the original exception to the application. Instead, it throws a new exception type.
If the application configuration information is not valid, the application block throws an exception of type System.Configuration.ConfigurationErrorsException. No information is logged before this exception is thrown.
If the configuration file is valid, the application block throws an exception of type ExceptionHandlingException. The application block uses the instrumentation setting to determine whether the original exception information should be logged. If instrumentation is enabled, the application block logs the original exception information in the Application Event Log before throwing the new exception.