Exception Providers
Exception providers can be used to publish exception information to a variety of sources. This is useful because user's of an application often fail to capture exception information when they encounter a failure. To address this, an ExceptionManager class could be developed to publish exception information to a collection of subscribers. These subscribers might be common destinations such as the event log, a table in a database, a file on disk, or an email address. When an exception is caught, something along the lines of:
try {
... some code ...
}
catch (System.Exception ex) {
ExceptionManager.Publish(ex);
}
could be used to invoke the functionality of a ExceptionManager class. The purpose of this is to capture that information whether or not the user chooses to report the problem and furthermore irrespective of whether that user captures all of the relevant information from the exception. A very mature version of this kind of idea is visible in most Microsoft applications with the familiar "Send Error Report" dialog. Whenever a Microsoft application encounters an unexpected error, a full report is prepared and saved to disk. The application then asks for permission to transmit the information about this error report to Microsoft. This allows a knowledge-base of known exception situations to be constructed in an automated fashion. Futhermore, if user's contact Microsoft about specific failures in their application, the mechanism for capturing the exception information is in place, even if that user typically clicks the "Don't Send" button. The information can still be captured when the user decides that they want to enlist the help of Microsoft to diagnose the problem. The exception handling and publishing provider model presented here is a very simplified version of that idea.
How is the provider model appropriate?
The ExceptionManager queries a configuration file to determine the list of exception publishers that are currently active. Each configured publisher is dynamically instantiated based upon the provider implementation that it cites in its configuration element. Because each publisher provider implements a known interface, say IExceptionInformationPublisher, the ExceptionManager class can call the methods on that interface to pass the exception information to each implemented publisher. Continuing the example above, assume that the IExceptionInformationPublisher interface contained a method with signature Publish(Exception ex), the ExceptionManager would call that method upon each publisher. The publishers then know how to process and publish that exception information to their specific destination. The complexities of writing to the event log are thus abstracted into that particular publisher provider's implementation, isolating those details not only from the application itself but also from the ExceptionManager class.
This leads to an exception information publishing framework with a configurable list of destinations for that information. If one of the publishers fails to record the information, including the user as a publisher, there is a good chance that some of the other publishers will succeed and the exception information will still be captured. This can be an invaluable tool for debugging and correcting errors within an application.
NOTE: Astute readers will realize that log4net comes with a lot of this functionality already built in and integrating log4net with an application will allow exception information to be published to a similar list of sources. While correct, it is important to remember that this is an instructional example. Log4net uses a provider model to provide its listener architecture, this example demonstrates how a provider model can be implemented.