Multiple or Single Try Catch [duplicate]

Solution 1:

I always try to reduce levels of nesting for readability and maintainability. If you have n try/catch blocks, each handling the same type of exception, why not refactor the code that can throw the exception into methods...it would look something like:

try {
    firstBatchOfTricky();
    secondBatchOfTricky();
    ....
    nthBatchOfTricky();
} catch (ItWentBoomException e) {
   // recover from boom
} catch (ItWentBangException e) {
   // recover from bang
}

This is much more readable than having multiple try/catches. Note that your methods should describe what they do in the spirit of self documenting code.

Since you have your own Exception type, you can add the data you need to the exception to do different things in the catch block. When you say 'more specific message', you can just throw the exception with the detailed message; you shouldn't need multiple catch blocks. If you want to do drastically different things based on the state of the exception, just create more exception types and catch blocks but only one try block, as my pseudocode shows...

Finally, if you can't recover from the exception(s), you should not clutter the code with catch blocks. Throw a runtime exception and let it bubble. (Good advice from @tony in the comments)

Solution 2:

This isn't a performance or personal preferences question: It's a functionality and requirements question.

Suppose I write:

Scenario 1:

try
{
  doThingA();
}
catch (SomeException panic)
{
  System.out.println("doThingA failed");
}
try
{
  doThingB();
}
catch (SomeException panic)
{
  System.out.println("doThingB failed");
}

Scenario 2:

try
{
  doThingA();
  doThingB();
}
catch (SomeException panic)
{
  System.out.println("doThingA or doThingB failed");
}

These two scenarios are not equivalent: They do different things. In Scenario 1, if doThingA throws the exception, doThingB still executes. In Scenario 2, if doThingA throws the exception, doThingB is not executed. So the question is not which gives better performance or which is more readable code, but rather, if doThingA fails, should doThingB still be executed or not?

If what you really want is the second behavior, but you want different messages to tell the user what went wrong, then you should either throw different exceptions, or put the text of the message into the exception, i.e.

void doThingA() throws SomeException
{
  ... whatever code ...
  if (theWorldIsAboutToEnd)
    throw new SomeException("doThingA failed");
}

Then in the catch clause, instead of displaying a constant string, displayt SomeException.toString or SomeException.getMessage.

Solution 3:

If the exceptions can be handled differently (different error message, etc.) then catching them separately is fine.

If the Exception types are different, that doesn't mean you have to have separate try blocks, you can have one try block with multiple catches.

Solution 4:

It's totally dependent on the scenario. If you do a bunch of stuff that throws a security exception and you handle that scenario the same way, you can use a try block for that.

However, having said that, using many smaller try/catch blocks is often better in my opinion. Using a big try/catch is like using several goto statements except you can't tell where the gotos are coming from.

Eg in the below how can you tell which method would go to exception1 and which would go to exception 2? It's fine if it's a small block but once it gets bigger, it becomes very unreadable.

try{
  doThing1();
  doThing2();
  doThing3();
  doThing4();
  doThing5();
  doThing6();
  doThing7();
  doThing8();
  doThing9();
} catch (Exception1 e){

} catch (Exception2 e){

}

Below is clearer.

try{
  doThing1();      
} catch (Exception1 e){ [...] } 
  doThing2();
  doThing3();
  doThing4();
  doThing5();
  doThing6();
  doThing7();
  doThing8();
try{
    doThing9();
} catch (Exception2 e){ [...] }

Solution 5:

My personal preference is a single try that may or may not have multiple catch blocks. My methods tend to be small enough where this makes sense. If yours are getting too long for that to be practical, perhaps you need to think about refactoring.

One thing about catch blocks: If your catch block prints or logs the stack trace and re-throws, I'd say that you would be better off adding the exception to the throws clause in the method signature and let it bubble up.