Exception Logging Block - Suggestions

Topics: Exception Handling Application Block, Logging Application Block
Mar 3, 2010 at 7:32 PM

After recently working with the Exception handling block to achieve some customer desired functionality, I came away with the following thoughts...

  • It seems the internal "plumbing" between the Formatters, Listeners and Handlers is all based on passing a String (StringBuilder). It seems like this would make logging of any binary data (i.e. an app that on Exception handling takes its own 'screen shot' would have a binary payload to log to a file) less accessible without conversion to a string-based payload... It seems like use of a Stream would have been a more flexible option...  Perhaps there are reasons why this wasn't done, but we had a case where binary serialization to a stream could have been more helpful.


  • We defined a primary exception handling/logging policy and wanted to use a fixed name across multiple projects. What we ran into though is that some of the underlying components we've made use of already had expected policy names hard-coded... I.e. the Web Client Software Factory uses the "GlobalExceptionLogger" policy name.... NeTiers (a DAL) has a "NoneExceptionPolicy" named in their generated code.  In these cases the names are not readily confgurable nor do we want to modify the underlying assets themselves.  In this case, having "aliases" or "forwarders" for these fixed-name policies would be helpful. I can't imagine this being too difficult to implement...


  •  Another customer requirement was that we have the ability to "fail over" from one exception handling approach to another.  I.e. the primary policy logs to a centralized database but in the event of an exception in that handler (this particular case uses a custom handler/formatter) we would like to invoke a 'failover' policy (this particular case it was a failover policy that used the standard eventlog/smtp handlers and standard text formatter)...  Allowing policies to cascade would have been helpful.  Instead in our custom database handler we catch any exceptions and basically call back to ExceptionPolicy.HandleException() to invoke the failover policy. Something 'purpose built' from the core codebase itself would be preferred to our custom one-off approach...



Mar 8, 2010 at 2:11 AM

On your third item:

Yes, there's no mechanism for a fail-over logging.  Another workaround for this aside from what you're doing is by creating a custom database trace listener which would log to the destination you want or invoke the policy you want in case of an exception.

On your other items, we'll try to get Microsoft's feedback on those.

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.

Jul 10, 2010 at 12:12 AM


On your first point: there is a BinaryLogFormatter.