Why use Finally in Try ... Catch

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 just skip the Finally section and just run it after, outside the try catch block?

Example 1, Try ... Catch ... Finally ... End Try

    Try
        'Do something
    Catch ex As Exception
        'Handle exception
    Finally
        'Do cleanup
    End Try

Example 2, Try ... Catch ... End Try ... Do the finally stuff outside

    Try
        'Do something
    Catch ex As Exception
        'Handle exception
    End Try
    'Do cleanup

Yes, it is different. Finally will always run (barring program crash). If the function exits inside of the try catch block, or another error is thrown in either the try or the catch, the finally will still execute. You won't get that functionality not using the finally statement.

Code with four radio buttons:

• Return in TRY

• Return in CATCH

• Throw in CATCH

• Finish CATCH

   private void checkFinally()
   {
       try
       {
           doFinally();
       }
       catch
       {
           Console.WriteLine(" Breaking news: a crash occured. ");
       }
   }
  
   private void doFinally()
   {
       Console.WriteLine(" ");
       Console.Write("Here goes: " 
           + (radioReturnInTry.Checked ? "2. Return in try: " 
                   : (radioReturnInCatch.Checked? "3. Retrun in catch: "
                       : (radioThrowInCatch.Checked? "4. Throw in catch: "
                           : "1. Continue in catch: "))) );
       try
       {
           if (radioReturnInTry.Checked)
           {
               Console.Write(" Returning in try. ");
               return;
           }
           Console.Write(" Throwing up in try.  ");
           throw new Exception("check your checkbox.");
       }
       catch (Exception ex)
       {
           Console.Write(" ...caughtcha! ");
           if (radioReturnInCatch.Checked)
           {
               Console.Write("Returning in catch. ");
               return;
           }
           if (radioThrowInCatch.Checked)
           {
               Console.Write(" Throwing up in catch. ");
               throw new Exception("after caught");
           }
       }
       finally { Console.Write(" Finally!!"); }
       Console.WriteLine(" Done!!!"); // before adding checkboxThrowInCatch, 
       // this would never happen (and was marked grey by ReSharper)
       
   }
  

---

Output:

• Here goes: 1. Continue in catch: Throwing up in try. ...caughtcha! Finally!! Done!!!
• Here goes: 2. Return in try: Returning in try. Finally!!
• Here goes: 3. Retrun in catch: Throwing up in try. ...caughtcha! Returning in catch. Finally!!
• Here goes: 4. Throw in catch: Throwing up in try. ...caughtcha! Throwing up in catch. Finally!! Breaking news: a crash occured.

---

To summarize: Finally takes care of two things:

1. Of code that returned in the try or in the catch.
2. Or If you had an exception in the try, AND THROW an exception in the catch,
3. or, if you had an exception in the try, AND DID NOT CATCH that exception,

Finally to summarize "FINALLY": Finally does nothing special if you tried,and

1. DID NOT RETURN,
2. and caught any exceptions during the trial, and then
3. DID NOT RETURN in the catch either, and
4. DID NOT THROW or have code that throws up.

And last but not least (finally): If you have an exception in your code that YOU DID NOT CATCH, your code will fly, WITHOUT REACHING THE FINALLY.

Hope this is clear. (Now it is to me...)

Moshe

The difference is when the code in the try block throws an exception that isn't caught by the catch block.

Normally a catch block would catch a specific type of exception, and let anything else through. In that case, the finally block will still run.

The finally block will also run if the code in the try block returns.

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.

This is a good idea when dealing with database connections or anytime objects need to be disposed of. Just in case something goes wrong while running queries, you can still close the connection safely. It also helps to clean up code that the block outside the try/catch/finally block is not able to access.

The Finally block will execute regardless of if the function exits because of an exception. (there are some exceptions to this rule, see this stackoverflow question for more info).

For example:

Try
    'Do something
Catch ex As Exception
    if 'Some Condition
       throw ex
    else
       'Handle exception
Finally
    'Do cleanup
End Try

In this case the Finally block will still be executed even though you may throw an exception out of the function.

This is a good practice to get into because it ensures that your cleanup code always executes. Of course using the Resoource Acquisition Is Initialization idiom is a much cleaner way of ensuring that resources get cleaned up, but I'm not versed enough in VB.net to know if this is possible to do.

Finally should be used to everything that needs to be done in order to keep a system consistent. This usually means release resources

Finally is always executed, no matter what exception was thrown. It should be used to release resources, in the following cases:

• Finalize a connection
• Close a file handler
• Free memory
• Close a database connection

Let me give a complete example. Imagine that that you are sending messages through the network. In pseudo-code:

// With finally                  |  //Without finally
try{                             |  try{  
  send_message()                 |    send_message() 
} catch(NetworkError){           |  } catch(NetworkError){ 
  deal_with_exception()          |    deal_with_exception()
} finally {                      |  }
  finalizes_connection()         |  finalizes_connection() 
}                                |

The only difference of both codes is when what is hold in the try block raises an exception that is not NetworkError, for example, MethodNotFound. In the first case, the method finalizes_connection() will be called, and in the second one, it will not.

A connection is naturally done through more than one program. So what happens in the case of a MethodNotFound exception to the other program? In the first case, your program will finish the connection and the other program and it will be happy. In the second case, the other program can be waiting for your response forever. What if the other program can only receive one connection per time? You just bugged the other program as well.

This would also apply for a file, for example, that you opened and other programs wouldn't be able to open for reading (in Windows). And for memory, it is never released and now you have a memory leak.

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

Doing clean up in a finally block is to ensure that it is run. If the catch block doesn't deal with the exception (ie. it just logs it), or even causes another exception, the code in the finally block will still run.

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.

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.

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.

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.

What I often use is (I encapsulated that into an aspect, but this is what I derived the aspect of):

public static DoLengthyProcessing(this Control control, Action<Control> action)
{
    Cursor oldCursor = control.Cursor
    try
    {
        control.Cursor = Cursors.WaitCursor;
        action(control);
    }
    catch (Exception ex)
    {
        ErrorHandler.Current.Handler(ex);
    }
    finally
    {
        control.Cursor = oldCursor;
    }
}

Or, use AOP (as I do).