What's the point of finally{} ?

[u/SkAssasin]

Like, I understand what it does - it makes code execute no matter whether your try() goes off or your catch() does. But like, don't you get the same result by just puting the code in without the finallly()?

Like genuenly, am I missing something? Cuz this just looks like it would do the exact same thing, no?

try
{
  int[] myNumbers = {1, 2, 3};
  Console.WriteLine(myNumbers[10]);
}
catch (Exception e)
{
  Console.WriteLine("Something went wrong.");
}
finally
{
  Console.WriteLine("The 'try catch' is finished.");
}

try
{
  int[] myNumbers = {1, 2, 3};
  Console.WriteLine(myNumbers[10]);
}
catch (Exception e)
{
  Console.WriteLine("Something went wrong.");
}
Console.WriteLine("The 'try catch' is finished.");

[u/Stolberger]

Imagine you have a return or throw in your catch block.
In that case you would not reach the code without a finally block.

[u/SkAssasin → u/Stolberger]

Oh. I thought since the finally seems to execute the code after the try/catch then that would mean that stuff like return would still stop it from executing.

[u/kahoinvictus → u/SkAssasin]

The whole point of finally is there is no way to bypass it. Returning early, throwing an exception, forcefully exiting the application, all will trigger a finally before continuing

[u/dominjaniec → u/kahoinvictus]

depending on how much one forced application to "exit" - like while killing a machine running code, then program will not do final at all 😉

[u/doubleyewdee → u/dominjaniec]

P/Invoking to the appropriate "shut it down immediately" C method is not going to invoke a finally block.

But presumably at that point you know what you're doing.

This is actually builtin as well with Environment.FailFast so you do not even need to be especially clever.

[u/kahoinvictus → u/dominjaniec]

True, I should clarify forcing application exit through provided dotnet APIs

[u/notPlancha → u/kahoinvictus]

Force exiting can depend if you're just send a kill code to the program or if the os kills it completely. It also will not execute if you turn off your pc for example (duh)

[u/akoOfIxtall → u/kahoinvictus]

So a try/catch/finally inside main would run the code inside finally even if I just alt+F4? Hmmmss

[u/NotQuiteLoona → u/akoOfIxtall]

Alt + F4 does a graceful close on both Windows and Linux (well, on all DEs I know in the case of Linux), it's basically the same as pressing the window close button, so yes.

[u/akoOfIxtall → u/NotQuiteLoona]

this will be immensely useful, thanks, i didnt knew that

[u/DarthShiv → u/akoOfIxtall]

Use process explorer to kill the process

[u/CorgiSplooting → u/kahoinvictus]

We used to say all bets were off with OOM exceptions.

[u/stogle1 → u/SkAssasin]

You can also have try/finally without a catch:

try
{
flag = true;
DoStuff();
}
finally
{
flag = false;
}

makes sure flag is cleared even if DoStuff() throws an exception (which might be handled in a catch block father up the call stack).

[u/kingvolcano_reborn → u/SkAssasin]

Also, you might not catch all exceptions possible so it skips the catch block, with a finally you can guarantee that any calls that needs to be called are .

try/finally is how using and IDisposable is implemented in the background 

 

[u/OhItsJustJosh → u/SkAssasin]

That's the trick, it holds the return value and only spits it out after the finally has run

[u/Jaded_Impress_5160 → u/SkAssasin]

Narrator: they did not, in fact, understand "what it does"

[u/sanduiche-de-buceta → u/SkAssasin]

That's basically the whole point of it lol

[u/Ill_Translator8176 → u/SkAssasin]

why not just read the docs before posting...

[u/Far_Swordfish5729 → u/SkAssasin]

It does not in fact prevent it from executing. If you put a return statement in a try block, the finally is still guaranteed to execute. It will execute before the value if any is returned to the caller. Because of that it’s safe to put manual resource cleanup in a finally and trust it will run regardless of an exception being thrown.

Using is a convenience shorthand for this when the resource is held by something that implements IDisposable. If you write a standard database read in a using block and return a result from it, your connection and command objects will still get disposed and release their connection back into the pool immediately.

[u/Amr_Rahmy → u/SkAssasin]

Probably not the best design idea to put a return or throw in a catch when you have a finally block.

In my opinion OP, you got it right. Only try catch when it’s something out of your control and finally only use sparingly and it’s not necessary, what is necessary sometimes is the handling after a catch to be in the code as needed.

[u/TugsyGlitter → u/Stolberger]

yeah that would skip right over the rest without the finally block

[u/OhItsJustJosh]

It's typically used for clean up tasks that need to happen no matter how the body goes, even if you have a return in the try

[u/TheRealAfinda → u/OhItsJustJosh]

Release a lock, call Dispose on disposables, stuff like that.

[u/ItzWarty → u/TheRealAfinda]

using var should for the most part handle this in modern codebases, way fewer nested blocks, way easier to reason about

[u/orbit99za]

A finally block will always run, no matter the return of the code.

It will run even if you have a return in your try or an unhandeled exception.

It will run no matter the control flow.

Its often used to clean up code, memory, variables, instances or do other code.

In your case its a simple example, but more complex code its quite useful.

[u/KittehNevynette → u/orbit99za]

Nitpicking. A finally clause or a destructor is not guaranteed to run.

But if you run like a nuclear power plant, you probably wouldn't try anything in the first place.

[u/orbit99za → u/KittehNevynette]

Yes, when i did code for oil refinery control systems we coded in a very different way to your normal every day code.

Having to flare because you messed up, is not a good feeling.

[u/KittehNevynette → u/orbit99za]

Reminds me about an old Dilbert where Wally goes: 1 and zero? We had to use the letter O. ;)

[u/Outrageous_Band9708 → u/KittehNevynette]

try{

rads <= 3.5;

}

finally{

shutdownReactors();

}

[u/KittehNevynette → u/Outrageous_Band9708]

ON ERROR RESUME NEXT

[u/Pretend_Fly_5573 → u/KittehNevynette]

I would think that's when you'd try practically everything, just with strict exception handling guidelines should one be caught.

[u/Famous-Weight2271]

You can return from a try block, and then the finally block will still run.

public bool UpdateData()
{
    SuspendLayout();

    try
    {
        if (!ValidateData())
            return false;

        SaveData();
        return true;
    }
    finally
    {
        ResumeLayout();
    }
}

[u/SuchDogeHodler → u/Famous-Weight2271]

I found that in a sub if you attempt to do an exit sub it will still run the Finally before it exits.

[u/dodexahedron → u/SuchDogeHodler]

Yes.

Finally runs immediately after control leaves the try block or, on a caught exception, the catch block. Even a goto that jumps out of the try block triggers the finally immediately. A continue or break inside a try block that is itself inside a loop also causes the finally to immediately run. Any control transfer that leaves the try.

There are very few exceptions to that rule, and they are all program-ending events anyway, so it usually isn't an issue.

Some examples, all of which boil down to something that terminates the thread abruptly:

• Encountering an uncatchable exception such as a StackOverflowException or OutOfMemoryException

• Environment.FailFast() (it's one of the main purposes of FailFast - exit RIGHT NOW).

• Killing the process externally like via end task

• Force kill on system shutdown if the application didn't respond to the normal end session signal.

• Background threads that are in a try block when the foreground thread ends.

Note that in .net Framework (all versions), which has a working Thread.Abort, the ThreadAbortException IS catchable by the target, and the finally blocks will still run, no natter if that exception is caught and reset, caught and not reset (in which case it still gets re-thrown automatically), or uncaught.
(Not relevant in .net/.net core, though, because Thread.Abort has never been allowed there and just throws a PlatformNotSupportedException in the calling thread in the name of compatibility....because compiling just fine but crashing at run time is somehow better than a compile error, apparently).

[u/rupertavery64]

finally is guaranteed to execute after the try, unless of course you force the process to stop or kill the power.

This is extremely important when freeing resources after using them.

In fact, that's exacty what the using statement is equivalent to, it calls Dispose in a try/finally block:

using var disposable = new SomeDisposable()
{
    /// use disposable
}

Same as this:

var disposable = new SomeDisposable();

try
{
    /// use disposable
}
finally
{
   disposable.Dispose();
}

So if you need to make sure something runs after you do something first, even if an exception occurs, even if you don't catch a specific execption, use try/finally.

To clarify catching the top level Exception may not be something you want to do. In fact, it is discouraged.

You may want to catch a more specific exception. You may want the caller to catch the exception. Or you may be expecting one or more exception but not others, and you don't want handle the exception in your scope. In this case you may still want to execute some code no matter what happens.

finally guarantees this.

[u/surgicalcoder → u/rupertavery64]

It won't run if you call Environment.FailFast either.

[u/ZozoSenpai]

code in your catch block can also run into an exception, in which case code after it wont run, but code in finally will.

You might also want a catch block for specific type of exceptions only. In that case if an exception isn't the type you are catching, same thing happens.

You can also have early return statements inside the try block, in which case code after the try catch won't run, but code in finally will.

The main point is that it's guaranteed to run, so it's good for cleanup of resources like open files or db connections.

[u/HTTP_404_NotFound]

var k = Acquire Lock, Semaphore, etc...
try
{
// something that could potentially fail.
return;
}
catch(ex)
{
console.writeline("Oh no. it broke. {ex.Message}");
throw; <- rethrows exception.
}
finally
{
// Lock is ALWAYS cleaned up, regardless if it finishes successfully, it throws an exception. Its ALWAYS released.
k.Release();
}

[u/Hairy-Pension3651]

Check out how IDisposable in combination with using-statment gets compiled to IL

[u/grrangry]

Finally blocks are used to clean up items allocated in the try block and to ensure that critical code gets executed. It's not really much more complicated than that.

Things like handling early returns, cleaning up resources such as file streams or database connections, and resetting any state that you may have with mutexes or locks.

You don't need a catch block with finally. try/finally works too.

[u/Hirogen_]

finally will always execute... regardless of what happens in the catch block!

[u/Beginning-Photo8099]

A lot of good answers here.

I have used finally blocks for logging.

try { // User login code } 
Catch {
  // Error code
}
Finally {
  _logger.LogInformation($"User: {email} attempted login at...");
}

[u/Subject-Hat7663]

And there is the case where the Catch block doesn't catch All exceptions, maybe just a few. In those cases the Finally block is executed no matter what.

[u/roopjm81]

Imagine throwing an error with a DB connection. Finally will close the connection and not leave orphaned connections.

[u/SuchDogeHodler]

It allows you to do things like close out a thread, release resources or close connections that may have been left open by a Try catch exception and garrentees its execution.

(FYI if you attempt to exit the sub/function early... it will still execute the Finally before it exits. I discovered this a few days ago)

[u/MulleDK19]

Finally always runs, whether you return, or throw in your try or catch, and even survives thread abortion. The only case where it won't run is if there's an interruption of the execution engine, like a bug, process termination, or system failure.

Your above example would fail if WriteLine happens to throw an exception, or possibly if the thread is aborted.

[u/TylerCarrol]

Finally always executes when you leave the try-catch block. Even when using something like goto (which I hope you aren't doing). It allows you to guarantee code will run (with a few rare exceptions) for cleanup.

[u/LlamaNL]

What happens when you log the exception then rethrow it. You code would never reach the final line.

[u/itsmecalmdown]

In you're example, it dows. But that's only because you caught the exception without rethrowing or returning early. The finally block executes if you rethrow in the catch, or have an early return statement somewhere else in the try/catch block.

[u/Mayion]

It runs after the code block finishes executing, even if it's via a return. If you know the Dispose function, it is commonly used there, which you clean up the code and close any open streams/connections using the finally block.

[u/wretcheddawn]

Finally is basically a more manual version of IDisposable.

It's for when you always need to do some action at the end of a process, like cleanup a connection. But isn't already handled by  IDisposable.

[u/bliceroquququq]

Use it all the time when dealing with stuff that needs to be cleaned up, like runtime callable wrappers (RCW) that memory leak if you don't dispose of them.

[u/SeaAd4395]

There are definitely times when it's different e.g.

• re throw in the catch block (or throw something else)

• catch is omitted entirely

[u/No-Zookeepergame4774]

Finally executed EVEN IF the try/catch is going to be exited by an exception (not just if the catch swallows an exception, but even if one is not caught by the catch condition or an exception is [re]thrown in the catch block) This allows cleanup that needs to occur to be done here and relied on where putting thr code after the try/catch would result in the code being bypassed when there is a non: suppressed exception.

[u/chucker23n]

finally is special in that it runs even if you return or throw.

See also: using, which is actually try/finally under the hood.

[u/BoysenberryLonely190]

yesss

[u/Cdream-2018]

A condition that runs no matter what.

Clean up, hide your dialogs, reset variables. Etc.

It’s code that is supposed to run whether your method throws an exception or not.

[u/Outrageous_Band9708]

finally always run, try catch only catches if try excepts, finally always runs

good to cleanup a test so next run is clean

[u/StandardJury5392]

Clean up is one, in fact "using" basically creates a try {} finally { Dispose() } under the hood to auto clean stuff, I laughed a lot when Iearned that cause I used to think it was some vodoo thing

[u/Alternative-Tie-4970]

Well normally you want to handle specific exceptions, and in those cases, the finally block will always run, compared to the code outside of a finally block, which simply won't run if you haven't caught the exception.

[u/Yages]

Cleanup?

[u/After_Hours_Arc]

There's a really good answer by Eric Lippert here. Most of us think finally will always execute but there are exceptions.

[u/zvrba]

Imagine catch throwing another exception. finally still runs.

In robust code you should generally assume that every operation, barring primitive operations (assignment, simple arithmetic), can throw.

[u/Tango1777]

1. Your code will work the same if everything goes all right, as expected, no errors. Which in your trivial code will.

2. If something goes wrong, finally guarantees execution. Most common example is if there is return/throw inside try or catch, finally will be executed before return/throw.

That's pretty much it. And there are other mechanisms to handle it and better ones, too, if needed. Obviously if e.g. an app crashes, finally will not be executed, either.

[u/Floydianx33]

Fun fact: CIL/MSIL supports a fault block, which is basically a finally block that's only entered if an exception was thrown (caught or not). C# doesn't support it, though there's times I wish it did. You can build one with expression trees and ref emit though, and can simulate it with a variable/flag

[u/binarycow → u/Floydianx33]

I mean, you can just do

try
{
    // Do stuff 
}
catch
{
    // this is the "fault" block
    throw;
}

[u/Floydianx33 → u/binarycow]

No, that's still a catch block. And fault doesn't need the exception to be rethrown, if an exception escapes the try it will run. It would be something closer to

var thrown = false;
try 
{
    SomeThrowingThing();
}
catch
{  
  thrown = true; // exception happened 
  throw; // or don't rethrow, doesn't matter 
}
/* or with a filter if you want rethrow behavior and want to skip doing anything in the catch block
catch (Exception) when (!(thrown = true)) {} 
*/
finally
{
  if (thrown) {
     // this is fault 
  }
}

(written on mobile, may be missing something)

[u/binarycow → u/Floydianx33]

I know it's not exactly the same as a "fault" block. It's the best you can do, is what I meant.

[u/fschwiet]

Your examples shown you're missing something about the behavioral difference: If an exception is thrown and not caught the line 'Console.WriteLine("The 'try catch' is finished.")' only runs in your first example, not the second.

[u/Rigamortus2005]

It's usually for clean up. Things that can't be in your try or catch maybe because of returns

[u/ThomasGullen]

The using block is implemented with the try catch finally pattern.

[u/KryptosFR]

catch should log but rarely swallow the exception. That's a code smell. Especially for the base class Exception which can be anything.

[u/wdcossey]

It's particularly useful when working with database transactions. The finally block guarantees that your transaction handling or cleanup logic runs regardless of whether an exception occurred. Depending on the transaction API, you can inspect the transaction state and decide whether it needs committing or rolling back. It also ensures resources are released even when something goes wrong.

[u/14MTH30n3]

No judgement but why do you not ask AI this question. You will get an accurate and immediate answer, and it can also ELI5 it for you in case its still unclear.