Usage of Exception handling block in Enterprise Library

Question

Hi all:

We have a ASP.NET application that uses the Exception Handling Application block to log our exception to a database (using logging block indirectly). This all working perfect. However, since it is using the exception handling block to log data, everytime we wanted to log, we'll have to new'd a System.Exception object. Since we are not throwing exception, there are no performance issue. However, we do have to create a new exception object everytime we want to log something. Is this a bad design?

Answer 1

I wouldn't say so. Its an exception handling block, not a logging block. Perhaps you should have used the EL's LAB instead?

BTW, I love and use ELMAH as an exception handling block. It also isn't designed for logging, just for handling exceptions and logging them for examination later. I think there is a way to raise an exception event without new-ing up an Exception object, however.

Answer 2

Since you are already using the Logging Application Block and the EL (even if it is indirectly) you should just be able to log to the database through it rather than newing up an exception solely for logging purposes.

I too love ELMAH for exception handling. I use that for unhandled exception logging and log4net for all other logging.

Answer 3

You can define a logging policy independently from an exception handling policy, they do not have to be used together.

Exception handling and logging are many times used together through chaining of listeners. For example, you could catch a specific error in a catch block and reference your exception handling policy, that also could include logging actions via logCategory.

On the other hand, to perform only logging of certain events/actions, just specify a log trace listener that is not referenced from an exception handling policy. Output your log message with a Trace.Write statement.

Anyway, if you create different policies you can chain listeners when needed for more flexibility.

Update: In your loggingConfiguration section, configure up another Trace Listener. Then you'll need to add the listener under the categorySources section of web.config. Shown below is to log to two sources, the event log and an xml file.

<categorySources>    
<add switchValue="All" name="Database Events">
 <listeners>
  <add name="Formatted EventLog TraceListener"/>
  <add name="XML TraceListener"/>
 </listeners>
</add></categorySources>

Under your exceptionHandling section, make sure you wire up your "Database Events" categorySource to your policy: (some detail omitted for readability)

<exceptionHandling>
<exceptionPolicies>
 <add name="Data Access Policy">
   <exceptionTypes>
    <add type="System.OverflowException, mscorlib, ... postHandlingAction="NotifyRethrow" name="OverflowException">
     <exceptionHandlers>
      <add logCategory="Database Events" eventId="100" ... severity="Critical" name="Logging Handler"/>
      <add exceptionMessage="Overflow Exception caught." ... >
     </exceptionHandlers>
    </add>
   </exceptionTypes>
 </add>  
</exceptionPolicies></exceptionHandling>

So the end result in this case is chaining two listeners which were referenced from a single policy. Note that it's handled from a system.overflow exception type -- just an example on how you can specify different handlers for different exceptions.

And of course you could just add a log file listener and call it from your code when you need to log an event/action without having to rely on exception handling. Let me know if you'd like more detail.