Exception Management Application Block – why oh why?

Some are some things which I hate about the Exception Management Application Block. This was one of the first app blocks and it shows:

1. The default debug information which the ExceptionManager gathers is HARDCODED in the ExceptionManager class. So you can either get stuck with loads of goo in the additionalInfo collection which you don’t want , or you can wrap it with more code to clean it up afterwards. This should have been extendable or at least configurable.

2. There is no way to categorize the debug information which is collected – each item  is stored as a key/value . So in order not to lose metadata, it gets stuffed into the key – for example:
         additionalInfo.Add(EXCEPTIONMANAGER_NAME + “.MachineName”, Environment.MachineName)

3. Whoever coded the block has never heard of coding standards. Many of the methods are over 100 lines long , the string concatenation (in VB.NET) is done using “+“ instead of “&“, and my favorite- variable names seem to be specifically designed to confuse the enemy.

Dim i As String
Dim j As Integer
Dim k As Integer

i as String? WTF ??

Anyway, anyone who is serious about logging/tracing should skip this AppBlock and take a look instead at it’s big brother – EIF.  EIF has much more advanced capabilites such as support for the Windows Trace Session Manager, WMI built-in, and aggregation of trace info from seperate tiers into one central repository.   Or try out some of the open sourced community libraries such as Log4Net.

Just my .02…





Comments (0)

Skip to main content