As luck would have it, I happened to be at Microsoft in Redmond this week while the local user group, Dot Net Users, was hosting Avanade's Tim Shakarian. Tim gave a very interesting talk about the upcoming Enterprise Library and dove into detail on the Exception Handling Application Block. Tom Hollander (PM on the Microsoft PAG team) was also present to help answer questions.
Here is a summary of my notes from the session:
Enterprise Library
Enterprise Library (EntLib) is a redevelopment of the Application Blocks currently hosted by the Patterns & Practices team at Microsoft. The blocks are “reusable software components designed to assist developers with common enterprise development challenges.” The EntLib is not currently available to the public, as they are now available only to Avanade, Microsoft and select partners (via the Enterprise Library Partner Program.) They are setting expectations that the EntLib will be available no sooner than January. During the intervening months, Avanade is rebuilding their Avanade Connected Architecture for .NET (ACA.NET) framework upon the services of the EntLib. (Note that the two are distinct efforts - EntLib are the free/community-based/open utilities, ACA.NET is a proprietary, more fully-featured framework which Avanade will use on client projects.)
When released, they will be part of the Microsoft Patterns & Practices library, free for use and will include all of the associated unit tests (current count is 1,900+) and documentation/samples in C# and VB.NET.
There is quite a bit of documentation available at GotDotNet. As Tim happily pointed out, the workspace is so popular that you can just go to the main GotDotNet Workspaces directory page and see it there. But here is the link.
The blocks include:
- Caching - It's for, uh, caching
- Security - Authentication, authorization, basic profile management, etc.
- Data Access - SQL Server, DB2 and Oracle will be supported out of the box
- Crypto - Easy-to-use but extensible encryption
- Exception Handling - (Described in detail below)
- Logging - Used individually or by other blocks to log messages to configured targets
- Configuration - Leveraged by the other blocks (see below)
They are all fully extensible, featuring pluggable providers, replaceable block implementations and guidelines on writing new blocks.
They are designed to work together (e.g. the Exception Handling leverages Logging, Security leverages Crypto, etc.), but they can be used individually.
Tim demonstrated the use of a windows-based Enterprise Library Configuration Console, which drives all EntLib settings for an app and modifies the appropriate .config file for the application to work with the proper EntLib settings. The Console can be extended to add your own custom creations.
Two additional versions are in the pipeline for EntLib. Version 2 will include more blocks for AOP and SOA, more community participation and an expanded Partner Program. Version 3 (release to coincide with Whidbey) will ensure the EntLib is compliant will all of the new platform's recommended practices.
Exception Handling Application Block
After the overview of the EntLib, Tim spent the remainder of the session giving an overview of the Exception Handling Application Block.
Here's an example invocation:
if (ExceptionPolicy.HandleException(ex, "MyPolicy"))
throw;
That's it. The power and flexibility lie in the configuration settings.
Basically, you define one or more Exception Policies. A Policy contains one or more Exception Types (e.g. “System.ArgumentException“.) And each Type contains one or more Exception Handlers.
Exception Handlers tell the system what to do when an Exception of the designated Type is received by the Policy. There will be three Handlers shipped with V1:
- LoggingExceptionHandler
- Uses Logging Application Block, but others could be plugged in (e.g. Log4Net)
- Defaults to event log.
- WrapHandler
- Wraps the original exception with a new Exception type, as specified in configuration
- The original Exception will remain available through the InnerExeption property
- ReplaceExceptionHandler
- Drops the original Exception and places a new Exception in its place (as configured)
Handlers always execute in a configured order. Each Handler has the opportunity to take some action upon the Exception (e.g. wrapping it) and the current exception is then passed along to the next Handler in the chain.
Once the configured Handlers have executed, there is a post-handling action which you can specify as one of the following:
- RethrowAction.None - No rethrow should occur
- RethrowAction.Notify - Tells the calling application that the Policy recommends the Exception should be rethrown.
- RethrowAction.Throw - Throws the resulting Exception to the calling application after all Handlers in the chain have executed. (Again, this may or may not be the original Exception.)
This explains why the (simple) code example above is based on an expression, not a fire-and-forget metaphor used with the current Exception Management Application Block.
The Block ships with two Formatters for logging or displaying Exception details: TextExceptionFormatter and XmlExceptionFormatter. The formatters use Reflection to iterate over any members of the Exception and create and output either in Text or XML. This is very similar to what the current Exception Management Application Block does. Note that the use of Reflection helps to automatically log any custom properties of your own Exception types.
You can easily create custom Handlers. Your class simply implements the very small IExceptionHandler interface. If you wish to have your Handler read settings from the configuration, it should also implement the IConfigurationProvider interface. Tim showed an example of this and it seemed very straightforward.
Being an active user of several of the current Application Blocks, I enthusiastically look forward to working with this new suite next year. Many thanks to Tim for a great presentation. I hope Tim will consider giving a similar talk to the Boston .NET User Group should he be in the area in the coming months!
-Chris