views:

426

answers:

1

I'm just starting to use the Enterprise Library Exception Handling block.

It seems a little cumbersome.

Do I really have to do

 try
 {
     //Do something with a DirectoryInfo object
 }
 catch(DirectoryNotFoundException ex)
 {
   bool rethrow = ExceptionPolicy.Handle(ex, _exceptionPolicyName);

   if(rethrow)
        throw;
 }

Everywhere I want to handle exceptions?

Or should I just wrap the top level in

 try
 {
     //Entrypoint code
 }
 catch(Exception ex)
 {
   bool rethrow = ExceptionPolicy.Handle(ex, _exceptionPolicyName);

   if(rethrow)
        throw;
 }

I was under the impression I could aspect this on with attributes?

+2  A: 

How many places do you need to handle exceptions?

This Application Block is mainly used for handling exceptions on the boundaries of layers. For instance, the top-level code of your Data Access Layer might use this so you can configure whether and how to log DAL exceptions, whether to wrap a non-DAL exception, etc. But your private, inner methods should not handle exceptions at all.

And no, EAL doesn't do attributes.

John Saunders
Ok this is good, I have various services working together to solve a problem. I guess logging is actually more relevant for my inner exceptions. I'm dealing with files and folders which tend to throw exceptions and lots of types of exceptions... Thanks this has helped.
Rob Stevenson-Leggett
Why more important for the inner ones. I meant the opposite. Cal the EAB at service and layer boundaries. Do not catch exceptions at low levels unless your logic will do something different with them, like wrapping IOException so you can add a filename or other context.
John Saunders