n an ideal world, all the code you write would always run without error. But the reality is that no matter how carefully you write your code, errors can and will occur. Therefore, it's imperative to have an efficient, configurable exception handling framework capable of handling errors in a graceful manner. It is also important to understand that people generally gauge the effectiveness of any exception handling solution by the way it impacts the user's experience with the application. So a good exception handling solution must not only handle errors gracefully from a user's viewpoint, but must also provide robust configuration settings through which developers or administrators can configure the error handling behavior. Key Components of Exception Handling Block

The new Exception Handling Application Block that ships with the Enterprise Library 2.0 has undergone huge improvements since the release of the old Exception Management Application Block. To use this block effectively, you need to absorb three main concepts:

• Exception Handling is the process of doing something with an exception when the exception is detected by your code.
• Exception Logging is the process of logging an exception, which might include sending formatted exceptions to the event log or sending an email message. The exception handling block makes use of the Logging and Instrumentation application block for this purpose.
• Exception Policies allow you to control exception handling and logging behaviors using external configuration files instead of baking such rules into your code. In other words, you can define the exception handling in a policy file and then change the behavior to accommodate the differing exception-handling needs during testing, debugging, and production scenarios without changing your code.

Using the exception handling block, there are three things you can do when you detect an exception in your code:

1. You can wrap the exception in a new exception to add new context information or detail. The original exception is still available through the InnerException property when the new exception is propagated up the call stack.
2. You can replace the exception with a new exception. You typically do this when you don't want the details of the original exception to be propagated across an application boundary.
3. You can log the exception. Of course, you can do this in combination with wrapping or replacing the exception, or you can log the original exception and propagate the original up the call stack.

You get the Exception Handling Block when you download the EntLib Caching Block from MSDN.