Key Scenarios

  • Article

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.

Exceptions That Occur During Exception Handling

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 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 block throws an exception of type ActivationException. No information is logged before this exception is thrown.

If the configuration file is valid, the block throws an exception of type ExceptionHandlingException. The block uses the instrumentation setting to determine whether the original exception information should be logged. If instrumentation is enabled, the block logs the original exception information in the Application Event Log before throwing the new exception.