Question

There are 3 permutations of a try…catch…finally block in java.

1. try…catch
2. try…catch…finally
3. try…finally

Once the finally block is executed, control goes to the next line after the finally block. If I remove the finally block and move all its statements to the line after the try…catch block, would that have the same effect as having them in the finally block?

Answer 1

I think willcode comes the closest to expressing the key point here, and probably everyone means it but are not clear.

The problem is there is indeed something very wrong with what you are asking: “If i write all the statements after catch block instead of writing them into finally block then then would there be anything wrong?”

If you write all the statements after the catch block, what you are implying is that

1) You will always catch the exception.

2) You will always continue on to the next statements after you catch the exception.

This implies that you will always continue the execution “normally” after an exception, which is generally something you never in fact want to do.

Exceptions should be just that – exceptional. If you can in fact handle an exception, it is always better to write your code to consider those conditions first and not lead to an exception at all. If you follow this model then exceptions are truly exceptional – conditions you could not anticipate or at most not fix. Really not anticipate is what you should work towards. This means in general you are unable to handle true exceptions, which also means you should not just continue execution, often you end the application instead.

What is normally done is you allow an error to propagate back up the call stack. Some say this is done on the off chance that someone higher up in the chain may be able to handle it. I would say that essentially never happens, there are two real purposes to do this. One it may be something the user can fix, if there is one. So you propagate the error back up until you get to where you can report it to the user. Or two, a user cannot fix it but you want to get the entire call stack for debugging. Then you catch it at the top to fail gracefully.

The finally block now should have more meaning to you. As everyone says it always runs. The clearest use of a finally is really in a try… finally block. What you are now saying is if the code runs fine, great. We still need to do some clean up and the finally always executes then we move on. But if an exception occurs, we now really need that finally block because we may still need to do some clean up, but we are no longer catching the exception here so we are not going to be moving on anymore. The finally block is essential to ensure that clean up occurs.

The idea of an exception always halting execution may be hard for someone to grasp until they have a certain amount of experience, but that is in fact the way to always do things. If an error happened, either it was so minor you should have accounted for it to begin with, or else there are just more and more errors waiting to happen down the line.

“Swallowing” errors – catching them and moving on is the worst thing you can do because your program becomes unpredictable and you cannot find and fix bugs.

Well written code will contain as many try … finally blocks as are necessary to make sure that resources are always released no matter the outcome. But well written code generally contain only a small number of try … catch blocks that exist primarily to allow an application to fail as gracefully as possible, or defer to the user, which means at least always pass a message to the user etc. But you usually do not just catch an error and keep going.