Is it bad practice to nest 2 try catch statements in C#?

Question

Is the following code bad practice?

 try //Try Overall Operation
      {
           try //Try section 1 of operation
               {

               }
           catch(exception ex)
               {
                    //handle exception code
                    //throw the exception
       }
 catch (exception ex)
      {
          // send soap exception back to SOAP client.
      }

I know from a program review point of view, other developers seeing 2 tries nested directly like that might wonder why, but is it totally taboo, or is it accepted practice now days?

Thanks Guys, I agree with you all about the refactoring, going to create a seperate method for the sub functionality, the method was getting really long. I am very impressed to all of you who picked this up...

Answer 1

In my opinion it doesn't have to be. Sometimes you want some code within the first try to execute even if the code in the second one fails.

Might also add that other people are right in what they're saying also. I'm just saying it doesnt have to be bad always. In a program that's not demanding performancewise you could just do it whatever way you like.

Answer 2

It's not terrible, however see if you can't just solve this by handling the Exception types as necessary instead:

try
{

} 
catch (SqlException ex )
{
// Catches specific exception
}
catch ( Exception ex )
{
// Catch-all
}

Everytime you do a try-catch you're creating another thread of statements that encumbers readabilitiy. E.g.:

try
{
   try
   {
   }
   catch ( Exception ex )
   {
   }
}
catch ( Exception ex )
{
}

Answer 3

It depends on what your program needs to do. It's generally best to wrap your try/catch around the smallest scope of work possible and focus your exception handling as narrowly as possible to avoid unexpected behavior, side effects or bugs. Many times this will mean having a sequence of try/catch blocks, which is fine.

Answer 4

No. I don't think this is bad practice at all.

If you are doing something in the first, nested try which you can catch and handle properly, this is perfectly fine, especially if you're "catching" different types of exceptions in the two handlers.

However, I would say that this is potentially a good opportunity for refactoring, and splitting the nested section into a separate method. Often, when I've seen this, it's a sign that the method should be split into smaller methods. However, this is not always true.

Answer 5

I think it depends on how you are handling the inner exception. It may be very logical that your inner catch there needs to do something completely different than would fall int the scope of the outer catch. The one thing you would want to avoid is hiding the inner exception as being the cause of the outer exception. In other words, I would highly recommend

try
{ 
     // Do something 
     try
     {
         // Do something
     }
     catch(MyException e)
     {
         // handle
         throw; // <--- This is important, it rethrows the same exception while maintaining the stack trace.  This is *different* from "throw e"
     }
}
catch(AnotherException e)
{
    // handle 
}

Answer 6

It's not bad practice, so long as the logic warrants it.

For example, if the outer-most try is for catching a SQL exception, and the inner-most try is for an IO exception, it might be reasonable to do this.

However, be careful to avoid having catch-all try clauses that cover a large number of lines of code. Those are not good practice.

Answer 7

No, it is not necessarily bad form.

Just like most of these types of questions (ie. Is goto evil?, Is for(;;) evil?) these things have their place and are ok if used when they are needed.

Answer 8

If there's an exception you can handle inside the first try block and still continue on successfully, I don't think there's any problem with it. If it's just to do something and re-throw, just add another catch block for the specific type of exception you are looking for and handle it there.