Why use Finally in Try … Catch

Question

I see that the Finally in Try .. Catch will always execute after any parts of the execution of the try catch block.

Is it any different to

Answer 1

Catch will not run after any parts of the execution of the try catch block. Catch will only run if an exception is thrown and the catch block can handle that type of exception.

The finally block is the one that will run when the try block is complete. By complete, I mean it finishes normally, or exits in some way (breaks out of a loop, returns from the method, throws an exception, etc.)

If you put the code outside the finally block and an exception is thrown (for example) then the code may not be executed if the exception is not caught, or it is rethrown in the catch block, or an new exception is thrown in the catch block. If you put it inside the finally block then it will be executed.

Basically, the clean up should be put in the finally block.

Answer 2

Finally contains code that needs to be evaluated at all conditions [whether or not an exception occurred].

There is no way to exit a try block without executing its finally block. If the finally block exists, it always executes. (This statement is true for all intents and purposes. There is a way to exit a try block without executing the finally block. If the code executes a System.exit(0); from within a try block, the application terminates without the finally executing. On the other hand, if you unplug the machine during a try block, the finally will not execute either.)

The main use is for disposing objects. It will be useful when you want to close user defined resources like file , opened resources(db stmts).

Edit

Also finally won't be executed after a stackoverflow exception.

Answer 3

you use finally for cleanup code, eg db connections or files that are open that needs to be close. Virtually any cleanup code that needs to execute regardsless of an exception or not

also, your exception handling might require to re throw the exception, or other exception, in which case the code after the block will not be executed

Answer 4

As far as I can remember I have never used a try/catch/finally block in my .NET code.

In general, catching exceptions in the middle tier is rarely needed. Exceptions are usually propagated to a top-level handler in the presentation tier (and possibly caught and rethrown at a tier boundary so they can be logged).

So in the middle tier you will more often see try/finally (or the "using" statement) so that resources are cleaned up. And in try/catch in the top-level handler in the presentation tier.

In the rare cases that I need to both catch an exception and do some cleanup, I would prefer to refactor so that the following:

try
{
    ... do something
}
catch
{
   ... handle exception
}
finally
{
   ... cleanup
}

becomes:

try
{
    DoSomethingAndCleanup();
}
catch
{
   ... handle exception
}

...
private void DoSomethingAndCleanup()
{
    try
    {
        ... do something
    }
    finally
    {
        ... cleanup
    }
}

IMHO this is much cleaner.

Answer 5

On top of what everyone else said, semantically I think that they are different.

Code in the finally block clearly states that you're doing finalization type tasks for the content contained within the try-catch. I think this makes it clearer to read.

Answer 6

After reading the reply to my comment above I came to think of a few things.

The question can basically not be answered completely with out knowing the code in question.

The reason being that not all code can be put in a finally block. E.g. yield statements are not allow in finally (and catch) blocks. The try block might have several execution braches where some returns and some don't. The finally being executed in all those case whereas in the example with no finally that would not be the case for the clean up code. Further more you can't jump (goto) into a finally block though very uncommon you can jump to the code after the catch block. You can't return from a finally block either.

There's quite a few although most very uncommon cases where the answer depends on the actual code.