Some questions on Logging Exceptions

Topics: Exception Handling Application Block
Jan 2, 2007 at 5:14 PM

I'm upgrading an application that is currently using a version of the old Exception Management block to use the Jan 2006 release of Enterprise library instead.

The basic requirements are that all errors must be logged to a database, that errors of certain types must also be sent via email, and that this can be configured without touching compiled code - pretty standard stuff.

I've played around with the error handling, logging and data access blocks, and have the following questions:

- How is additional contextual information supplied with an exception when handling the exception? I can't see a way of passing a dictionary object to the ExceptionPolicy.HandleException() method, which replaces the ExceptionManager.Publish() method in application code. I need to be able to add important data to the error that is only in scope at the point where the handler code is executing, such as session ID.

- Does anyone use the database listener in the logging block for logging exceptions? I tried using it with the default database schema and procs, but didn't find it appropriate for error management at all, as you cannot query the log table on error-related information such as exception type, source, stack trace and context info - everything is just a log entry.

Jan 3, 2007 at 12:38 AM
Regarding the first question, you can put additional context information into the exception's Data property. The logging handler will pass this data to the logging block via the LogEntry's Extended Properties.

Re the second question, the logging DB schema wasn't optimized for this purpose, so you may want to modify the schema and the DatabaseTraceListener to better meet your needs. You could also consider subclassing LogEntry with an ExceptionLogEntry which included some additional strongly-typed properties related to the exception, which could be accessed directly by your TraceListeners.