How to structure code with 2 methods, one after another, which throw the same two exceptions?

I have two methods, one called straight after another, which both throw the exact same 2 exceptions (IF an erroneous condition occurs, not stating that I'm getting exceptions).

For this, should I write seperate try and catch blocks with the one statement in each try block and catch both exceptions (Both of which I can handle as I checked MSDN class library reference and there is something I can do, eg, re-open SqlConnection or run a query and not a stored proc which does not exist). So code like this:

try
{
  obj.Open();
 }

 catch (SqlException)
 {
   // Take action here.
 }


 catch (InvalidOperationException)
 {
   // Take action here.
 }

And likewise for the other method I call straight after. This seems like a very messy way of coding. The other way is to code with the exception variable (that is ommited as I am using AOP to log the exception details, using a class-level attribute). Doing this, this could aid开发者_StackOverflow中文版 me in finding out which method caused an exception and then taking action accordingly. Is this the best approach or is there another best practise altogether?

I also assume that, as only these two methods are thrown, I do not need to catch Exception as that would be for an exception I cannot handle (causes way out of my control).

Thanks

You shouldn't catch an exception unless you can handle it in a sensible way and recover from the error. With that in mind, you should either choose not to catch these exceptions, or else you should catch them and do something useful and continue.

Assuming that you are trying to do the latter: handle the error and continue, does it really makes sense to do the same thing no matter which of the two statements fails? Assume you have this:

try {
    f1();
    f2();
} catch (FooException) {
    // Recover from error and continue
}

f3();

In this case if f1() fails and you recover from the error, f2() will never be executed - it goes straight to f3(). Is that really what you want? Maybe it is sometimes... but not usually.

More likely, after the error from f1() you either want to quit completely with an error or to recover and then go on to execute f2(). If so then you would need two separate try/catch blocks.

If you're not interested in recovery but just logging the exceptions then the simplest way is to let them propagate and catch them at a higher level (but before your program crashes or becomes unusable) and log the message and stack trace. This ensures that you will log all exceptions and saves you having to insert try/catch and logging code in every method that could throw.

You're right that you shouldn't be catching Exception.

Generally you need as many catch clauses as you have different recovery approaches. If the recovery behavior is different for these two methods, I see nothing wrong with using a try/catch for each.

Especially consider whether you'd run the second method after successfully recovering the first. If so, you definitely don't want to put the second method in the same try block where it will be skipped by the exception.

You could create a method that accepts an Action parameter:

void trySomething(Action mightThrow)
{
    try
    {
        mightThrow();
    }
    catch(SqlException)
    {
    }
    catch(InvalidOperationException)
    {
    }
}

Then you can get the name of the method that threw by mightThrow.Method.Name.