Multiple try-catch or one?

Exception Handling

Exception Handling Problem Overview


Normally, I'd do this:

try
{
    code

    code that might throw an anticipated exception you want to handle

    code

    code that might throw an anticipated exception you want to handle

    code
}
catch 
{

}

Are there any benefits to doing it this way?

code

try
{
    code that might throw an anticipated exception you want to handle
}
catch
{
}

code

try
{
    code that might throw an anticipated exception you want to handle
}
catch
{
}

code

Update:

I originally asked this question w/reference to C#, but as A. Levy commented, it could apply to any exception handling language, so I made the tags reflect that.

Exception Handling Solutions


Solution 1 - Exception Handling

It depends. If you want to provide special handling for specific errors then use multiple catch blocks:

try
{ 
    // code that throws an exception
    // this line won't execute
}
catch (StackOverflowException ex)
{
    // special handling for StackOverflowException 
}
catch (Exception ex)
{
   // all others
}

If, however, the intent is to handle an exception and continue executing, place the code in separate try-catch blocks:

try
{ 
    // code that throws an exception

}
catch (Exception ex)
{
   // handle
}

try
{ 
    // this code will execute unless the previous catch block 
    // throws an exception (re-throw or new exception) 
}
catch (Exception ex)
{
   // handle
}

Solution 2 - Exception Handling

If I could choose the second I would probably separate this into two functions.

Solution 3 - Exception Handling

Neither, just use multiple catch blocks for specific exceptions (unless there is just a ton of code in the block and only a couple of lines may throw an exception.In that case I would go with the second method).

Solution 4 - Exception Handling

You're thinking about this the wrong way. What do you need to do in your catch blocks? If you would recover from any of the possible exceptions by running the same code, no matter which operation threw the exception, then use one catch block. If you need to do different clean-up operations depending on which operation threw, then use multiple catch blocks.

Also, if you can use try/finally or the RAII pattern instead of try/catch, then you should.

Solution 5 - Exception Handling

Second method is better in my opinion because it allows you to trap errors with more accuracy.

Also wrapping your entire code inside one big try/catch block is bad, if your app has some sort of problem and it crashes but since you trapped a big generic execption the chance that you can actualy handle it correctly is lower. You should have spesfic parts inside try catch, like if your reading a file or taking user input. That way you can better handle that exeception

Solution 6 - Exception Handling

There are time we want to show specific error to user.

try{
   try{
      ... send message
   }
   catch(exception e){
    ...log error
    ...rethrow  send related error/show custom error
   }
   try{
       ...try to receive response
   }
   catch(exception e){
       ...show receive related error
   }
   //finally close the connection
   }finally{
        ...close connection
   }

Solution 7 - Exception Handling

I prefer the second method - it makes debugging easier, error handling more accurate and also feeds nicely into your unit testing nicely too.

Solution 8 - Exception Handling

I would go for the 2nd option, but whenever I see this code pattern my first feeling is to think about splitting it into multiple functions/methods. Obviously whether to do so depends on what the code is doing ;)

Solution 9 - Exception Handling

It depends on the nature of the type of errors happen in your code.

  1. If the handling of those errors you are going to do is same go for single try ... catch for that group of code. Else it will be too tedious.

  2. If the errors required different handling, separate it because you have to.

DO NOT APPLY A SINGLE METHOD FOR ALL CASES. PROGRAMMING MOST OF THE TIME IS CONTEXT SPECIFIC :)

You need to reach a balance of "GOOD/COMPLEX" and "BAD/SIMPLE". The more you code, you will be less stuck in this kind of dilemma :)

Happy programming!

Solution 10 - Exception Handling

Second method. Keeping the code that might throw an exception separate from other code - keeps the section smaller and easier to manage instead of wrapping all code, even that which will not throw exceptions.

Solution 11 - Exception Handling

2nd way but ideally use code guards - try/catch can be costly, if you catch an exception.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSteveView Question on Stackoverflow
Solution 1 - Exception HandlingJamie IdeView Answer on Stackoverflow
Solution 2 - Exception HandlingDarin DimitrovView Answer on Stackoverflow
Solution 3 - Exception HandlingEd S.View Answer on Stackoverflow
Solution 4 - Exception HandlingzwolView Answer on Stackoverflow
Solution 5 - Exception HandlingEKSView Answer on Stackoverflow
Solution 6 - Exception HandlingAshburn RKView Answer on Stackoverflow
Solution 7 - Exception HandlingAndyView Answer on Stackoverflow
Solution 8 - Exception HandlingbarrylloydView Answer on Stackoverflow
Solution 9 - Exception HandlingttchongView Answer on Stackoverflow
Solution 10 - Exception HandlingMark SchultheissView Answer on Stackoverflow
Solution 11 - Exception HandlingPhil CView Answer on Stackoverflow