Using Policy-Based Exception Handling
The previous example showed how to create a policy named "Global Policy" and map that to a custom exception handler that implements the policy logic. This section examines how the Exception Handling block simplifies the process by providing built-in policies that you can use to process run-time exceptions.
You need the same boilerplate code to handle an exception as in the previous example:
try
{
//Some code
}
catch(Exception ex)
{
bool rethrow = ExceptionPolicy.HandleException
(ex, <Name Of Policy>);
if (rethrow)
throw;
}
Remember, the second argument to the
HandleException() method is the name of the policy that you would like to apply for processing the exception. By default, the Exception Handling block ships with the policies shown in Table 1.
Table 1: Built-In Exception Policies: These four policies ship with the Exception Handling block.
Policy |
Description |
Logging Policy |
As the name suggests, this policy lets you log formatted exception information in locations as specified in the configuration file. |
Replace Policy |
This policy is useful when you want to replace the original exception with another exception for security reasons. |
Wrap Policy |
This policy lets you wrap an exception within a different exception; in other words, this policy creates a new exception of a defined type and sets the original exception as the InnerException object of the new exception. |
Propagate Policy |
This policy allows you to propagate an exception up through the call stack so that other layers of the application can process the exception. |
In addition to these policies, you can specify a custom policy name, and then implement a corresponding exception handler class to process the exceptions as shown previously.
Using Logging Policy
With that overview in mind, here's a more in-depth look at the code required to log exceptions using logging policies. First, add the "Log Only Policy" element as a child element of the
<exceptionPolicies> element in the
app.config file.
<add name="Log Only Policy">
<exceptionTypes>
<add name="Exception"
type="System.Exception, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
postHandlingAction="None">
<exceptionHandlers>
<add logCategory="Default Category"
eventId="100" severity="Error"
title="Exception Management
Application Exception"
priority="0"
formatterType="Microsoft.
Practices.EnterpriseLibrary.
ExceptionHandling.
TextExceptionFormatter,
Microsoft.Practices.
EnterpriseLibrary.
ExceptionHandling"
name="Logging Handler"
type="Microsoft.Practices.
EnterpriseLibrary.
ExceptionHandling.Logging.
LoggingExceptionHandler,
Microsoft.Practices.
EnterpriseLibrary.
ExceptionHandling.Logging"/>
</exceptionHandlers>
</add>
</exceptionTypes>
</add>
Just as with the exception policies, you specify the logging configuration information (such as the log store, log formatting information, and so on) in the
app.config file. This example adds the entries to the
app.config file required to use the event log as the log store. For a full example of this configuration, check out the
app.config file in the
downloadable code for this article.
Now add a CommandButton named
btnLogException to the form, and modify its
Click event as follows:
private void btnLogException_Click(
object sender, EventArgs e)
{
try
{
throw new Exception ("This is a sample exception");
}
catch (Exception ex)
{
bool rethrow = ExceptionPolicy.HandleException
 | |
Figure 3. Log Only Exception: When you inspect the Application Event Log after running the Log Only exception example, you'll see the logged information in the format specified by the configuration. |
(ex, "Log Only Policy");
if (rethrow)
{
throw;
}
}
}
The code in the
catch block passes the exception object and the exception policy name ("Log Only Policy" in this case) to the the
ExceptionPolicy.HandleException() method.
Run the application and press F5. The error is thrown and logged, but this time you won't see a MessageBox; however, if you open Windows Event Viewer you will see that the application logged an entry to the Application Event Log. If you click on that entry you'll see a dialog similar to the one shown in
Figure 3.