How many statements are there in a try / catch statement?

Question

Should I put multiple statements in try and then catch all possible exceptions, or should I only put one statement in a try statement?

Example:

try { MaybeThrowIOException(); MaybeThrowFooBarException(); return true; } catch (IOException e) { // ... } catch (FooBarException e) { // ... } 

or

 try { MaybeThrowIOException(); } catch (IOException e) { // ... } try { MaybeThrowFooBarException(); } catch (FooBarException e) { // ... } return true; 

Answer 1

Wrap your critical pieces so your message is clear and accurate.

Answer 2

The more statements you submit, the less specific the reasons for exclusion may be.

But, of course, it depends on whether the functions of the calls / operators have overlapping exceptions, i.e. if all exceptions can be taken into account in a certain way, then this is still normal.

In your example, you seem to have overlap exceptions, so your first form is fine.

Answer 3

It depends on the case, but it is important to note that in the first case MaybeThrowFooBarException () is nerver if MaybeThrowIOException () throws an exception, and in the second case MaybeThrowFooBarException will always be thrown if the exception is not thrown in the first catch

Answer 4

I think that the best practice is what is described in the book "Pragmatic Programmer" , exceptions are rarely used, but when using it should be cleared of what seems to be handled.

So my voice is example number 2.

Answer 5

You can handle multiple types of exceptions through a single try / catch loop. But take care of the order in which you are going to handle exceptions. The catch exception blocking block matters.

Answer 6

I think your first example is a better practice than the second.

Answer 7

According to what jldupont says, I try to always separate my potential risk operators from multiple try / catch blocks. That way, when something goes wrong, you know exactly where it was, and you can have specific error messages for each problem.

Answer 8

You can use any of them.

but if you use the first, then you should catch more specific exceptions.

Answer 9

You can usually separate what you are trying to do in a specific task. Put the code associated with this task in one catch attempt, and then if something goes wrong, you know that the task failed, and you can try to restore it there.

I find this method by reducing the amount of catch code you need to write and keep the related logic together.

Answer 10

The first choice, it allows a more understandable and readable code, especially since your procedure or function should try to make a very specific action, the fact that you have two separate calls that can throw 2 separate exceptions means that it does more, what it should be, perhaps it is necessary

Either spit 2 calls to 2 separate methods or go to the first approach.

The only reason you can go with the second approach is because your method performs 2 actions and a little more, but you want to process only 2 lines of code for exceptions and possibly wrap them and continue execution, but this is not recommended

Answer 11

I would prefer to use several statements in the try block, and then catch all possible exceptions. I don’t know why, but I always do it when I code

Answer 12

If they are truly separate, then the first is best practice, simply because it is shorter.

However, if it is possible for MaybeThrowFooBarException() to throw FooBarException or for MaybeThrowFooBarException() to throw an IOException , then you should only wrap them together if you want them both to take the same action on the exception!

Answer 13

If the method you call can return FooExeption () and BarException (), and you want to catch them, then the first example makes the most sense - there are quite a few APIs, especially those that have a higher level (since they themselves use more things that may cause exceptions).

If you do two separate things, it really depends entirely on what you want the result to be as follows:

• If the exception ends up being the same as for your code, and you don’t need to return anything back (or just roll back from it, and you can easily do it in one finally block - assuming the language supports this) then it makes no sense to have two separate try / catch blocks.

• If the types of errors are very diverse, and it is important for you what happens if the first method throws an exception (for example, and you need to perform some operations to roll back), and you want to continue the second operation, even if the first throws an exception, then the second approach would be more appropriate.

• If you don’t like it, if the first method fails, and you don’t want to continue execution, if so, then you should remember that you can insert try / catch, although it’s better not to go over with this. If it is used well, it is much clearer than trying to follow the bools in if statements to check whether a block should execute or not.

eg.

 try { MaybeThrowFooException(); try { // Will only be called as long as MaybeThrowFooException() is not thrown MaybeThrowBarException(); } catch (BarException ex) { } } catch (FooException ex) { }