Eliminating repetitive try/catch code

Question

Writing code which has to handle the same exceptions time and time again constantly gets boring.

Is there a way to write code, without try/catch, and add attributes to the method to catch (and handle) the various exceptions which may occur? This sounds like AOP (Postsharp), would this be the ideal solution?

So I want to write classes which can dictate where/how an exception is logged, rethrown, etc, and they derive from attributes and any base class/interface. And then re-use these and apply them to different methods throughout the code. This will greatly improve consistency.

Thanks

I somewhat rarely find myself using try/catches. They are typically handled by a global exception handler, be it ASP.NET, WCF, etc. Where/when do you find youself catching exceptions? — Kirk Woll, Jul 15 '11 at 23:36

Peter O. · Answer 1 · 2011-07-16T01:17:12.443

3

What I would suggest is write methods that take delegates (such as Func and Action) as arguments. The delegates would represent the "try" block. The individual methods would handle exceptions that occur within the delegates in different ways.

Example:

 OverflowHandler(delegate(){ checked{ x+=200; } });

where the OverflowHandler method would handle the OverflowException and would probably log and rethrow other exceptions.

Here is an example of how the OverflowHandler method could look:

 public void OverflowHandler(Action func){
    try {
       func(); // call the delegate
    } catch(Exception e){
       if(e is OverflowException){
          // handle the overflow exception
       } else {
          // log exception and rethrow
          LogException(e);
          throw;
       }
    }
 }

edited Jul 16 '11 at 01:17

answered Jul 15 '11 at 23:35

Peter O.

32,158
14
82
96

I see what you mean. In the delegate block, I could put try/catch? – GurdeepS Jul 15 '11 at 23:51
No, you would use a `try`/`catch` block in the method that handles the exception, in this case, OverflowHandler. That method's `try` block would call the delegate passed to that method. – Peter O. Jul 15 '11 at 23:55
I've edited my answer to illustrate an exception handler method and to better show that you don't put a try/catch block within the delegate block. – Peter O. Jul 16 '11 at 01:18

sgtz · Answer 2 · 2011-07-15T23:45:46.183

Here's something from the MS Practices and Patterns team.

Introduction to the Exception Handling Application Block http://msdn.microsoft.com/en-us/library/ff664698(v=PandP.50).aspx

definitely they've got the concept of rethrow + various policies in there.

Do I recommend it? Not sure. I looked at their implementation and ended up using some of their concepts. I told myself I'd come back to it, but I haven't had a chance yet.

score 0 · Accepted Answer · answered Jul 15 '11 at 23:40

It does sound like you're looking for functionality that AOP can provide. Depending on what you're specifically going for, you might be able to get a lot of the same benefits without the extra overhead simply by writing some helper methods, the way Peter O. suggests.

I personally don't find that I have a lot of repetitive exception handling code due to the fact that Exceptions are... well... exceptional. They shouldn't be part of the normal code flow, and unless there's something very specific that needs to be done in response to a specific type of Exception, the best policy is generally not to catch them at all, at least until they trickle up to a high level where you want to log them.

The problem I find is that I have code which may open files, but with different logic, and the same exceptions need to be caught, hence the repetition. — GurdeepS, Jul 15 '11 at 23:49

Eliminating repetitive try/catch code

3 Answers3

Linked