Is this sort of Java exception style bad practice?

Question

Is it considered bad practice to structure the code like this?

public void whatever() {
   try {
     methodThatMayThrowIOException();
   } catch(IOException io) {
     // do something with exception here
   }

   // do more stuff here that won't throw exceptions

   try {
     methodThatMayThrowCustomException();
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

Answer 1

Looks OK but it depends on what methodThatMayThrowIOException and methodThatMayThrowCustomException do and whether failure of the first one (methodThatMayThrowIOException) should fail the whole whatever method.

Answer 2

I don't see why that would be bad practice, as long as you actually do something useful with the exceptions you caught.

Answer 3

If the method can continue execution, without any problems even if the specified exception occurs this should be fine.

In the event where the exception should cause problems further down the line in the method, I would have it bubble up.

Answer 4

No it's not. It is a good point to catch specific exceptions when they might be thrown, imho it is surely better than this:

public void whatever {
    try {
        methodThatMayThrowIOException();
        // do more stuff here that won't throw exceptions
        methodThatMayThrowCustomException();
    } catch(ParentException e) {
        // do something with custom exception here
    }
}

Answer 5

well it depends on what you are trying to accomplish. you would normally enclose a block of code in a single try-catch block if the code block should be executed as a block or not at all if some exception occurs. if it's not the case, then i believe it is much better to isolate the different code blocks throwing different exceptions into different try-catch blocks sandwitching "do more stuff here that does not throw exception". just a thought!

Answer 6

It really depends on what you plan to do if an IOException thrown. Your style allows you to do more things, but if you're not actually planning to take advantage of that, then that intention is made much clearer by using the standard idiom.

public void whatever {
   try {
     methodThatMayThrowIOException();
     // do more stuff here that won't throw exceptions
     methodThatMayThrowCustomException();
   } catch(IOException io) {
     // do something with io exception here
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

Here you can tell quickly that if IOException is thrown, then you only do what's inside the catch block and not much else.

Answer 7

There is no problem with this, AFAICS. However, 2 try-catch in a method stabs in my eyes. If you feel the same, I suggest you to refactor it in a proper way.

Answer 8

No. That's a pretty good practice to narrow down the scope where some kind of exceptions are thrown. I did this a lot in my code.

However, if you are sure that in one try...catch block, certain kind of Exception will only be thrown by a unique function, putting them in the same try block is also OK.

Answer 9

Personally, I think it looks cluttered. I prefer to have just one try, with as many catch blocks as I need. I don't care or multiple try/catch sequences in a single method.

Answer 10

Your code reads like it does because you want to do part 1 (and resolve, catching IOException if necessary), do the no-exceptions part, and then do the methodThatMayThrowCustomException. Your code can literally not be written any other way and retain the same functionality. That's an exaggeration, but any other version would be different in a superficial sense.

This is not the same:

public void whatever {
   try {
     methodThatMayThrowIOException();
     // do more stuff here that won't throw exceptions
     methodThatMayThrowCustomException();
   } catch(IOException io) {
     // do something with io exception here
   } catch(CustomException ce) {
     // do something with custom exception here
   }
}

and the way it would execute if any of the Exceptions are thrown is quite different. If you need to sequentially recover from Part 1, hit Part 2 in any case, then carry on to Part 3, you cannot really write your code any other way.

There's nothing wrong with having two catch blocks, though mixing something that causes an IOException with something that throws a CustomException might suggest a mixing of concerns, making your code hard to understand. But as it is, it's not just valid, it's the only way to do what you're doing.