Does 'finally' always execute in Python?

Question

For any possible try-finally block in Python, is it guaranteed that the finally block will always be executed?

For example, let’s say I return while in an except block:

try: 1/0 except ZeroDivisionError: return finally: print("Does this code run?")

Or maybe I re-raise an Exception:

try: 1/0 except ZeroDivisionError: raise finally: print("What about this code?")

Testing shows that finally does get executed for the above examples, but I imagine there are other scenarios I haven't thought of.

Are there any scenarios in which a finally block can fail to execute in Python?

The only case I can imagine finally fail to execute or "defeat its purpose" is during an infinite loop, sys.exit or a forced interrupt. The documentation states that finally is always executed, so I'd go with that. — Xay
– Xay, Commented Mar 13, 2018 at 17:40
finally will not execute if the power cord is ripped from the wall. — Stack Exchange Broke The Law
– Stack Exchange Broke The Law, Commented Mar 13, 2018 at 20:33
You might be interested in this answer to the same question about C#: stackoverflow.com/a/10260233/88656 — Eric Lippert
– Eric Lippert, Commented Mar 14, 2018 at 14:40
@Xay sys.exit does nothing but throw an exception. Quite the misnomer. — Voo
– Voo, Commented Mar 15, 2018 at 12:01

user2357112 · Accepted Answer · 2018-03-29 16:54:39Z

"Guaranteed" is a much stronger word than any implementation of finally deserves. What is guaranteed is that if execution flows out of the whole try-finally construct, it will pass through the finally to do so. What is not guaranteed is that execution will flow out of the try-finally.

A finally in a generator or async coroutine might never run, if the object never executes to conclusion. There are a lot of ways that could happen; here's one:
```
def gen(text): try: for line in text: try: yield int(line) except: # Ignore blank lines - but catch too much! pass finally: print('Doing important cleanup') text = ['1', '', '2', '', '3'] if any(n > 1 for n in gen(text)): print('Found a number') print('Oops, no cleanup.') 
```
Note that this example is a bit tricky: when the generator is garbage collected, Python attempts to run the finally block by throwing in a GeneratorExit exception, but here we catch that exception and then yield again, at which point Python prints a warning ("generator ignored GeneratorExit") and gives up. See PEP 342 (Coroutines via Enhanced Generators) for details.

Other ways a generator or coroutine might not execute to conclusion include if the object is just never GC'ed (yes, that's possible, even in CPython), or if an async with awaits in __aexit__, or if the object awaits or yields in a finally block. This list is not intended to be exhaustive.
A finally in a daemon thread might never execute if all non-daemon threads exit first.
os._exit will halt the process immediately without executing finally blocks.
os.fork may cause finally blocks to execute twice. As well as just the normal problems you'd expect from things happening twice, this could cause concurrent access conflicts (crashes, stalls, ...) if access to shared resources is not correctly synchronized.

Since multiprocessing uses fork-without-exec to create worker processes when using the fork start method (the default on Unix), and then calls os._exit in the worker once the worker's job is done, finally and multiprocessing interaction can be problematic (example).
A C-level segmentation fault will prevent finally blocks from running.
kill -SIGKILL will prevent finally blocks from running. SIGTERM and SIGHUP will also prevent finally blocks from running unless you install a handler to control the shutdown yourself; by default, Python does not handle SIGTERM or SIGHUP.
An exception in finally can prevent cleanup from completing. One particularly noteworthy case is if the user hits control-C just as we're starting to execute the finally block. Python will raise a KeyboardInterrupt and skip every line of the finally block's contents. (KeyboardInterrupt-safe code is very hard to write).
If the computer loses power, or if it hibernates and doesn't wake up, finally blocks won't run.

The finally block is not a transaction system; it doesn't provide atomicity guarantees or anything of the sort. Some of these examples might seem obvious, but it's easy to forget such things can happen and rely on finally for too much.

I believe only the first point of your list is really relevant, and there is an easy way to avoid it: 1) never use a bare except, and never catch GeneratorExit inside a generator. The points about threads/killing the process/segfaulting/power off are expected, python can't do magic. Also: exceptions in finally are obviously a problem but this does not change the fact that the control flow was moved to the finally block. Regarding Ctrl+C, you can add a signal handler that ignores it, or simply "schedules" a clean shutdown after the current operation is completed.
The mentioning of kill -9 is technically correct, but a bit unfair. No program written in any language runs any code upon receiving a kill -9. In fact, no program ever receives a kill -9 at all, so even if it wanted to, it couldn't execute anything. That's the whole point of kill -9.
@Tom: The point about kill -9 didn't specify a language. And frankly, it needs repeating, because it sits in a blind spot. Too many people forget, or don't realize, that their program could be stopped dead in its tracks without even being allowed to clean up.
@GiacomoAlzetta: There are people out there relying on finally blocks as if they provided transactional guarantees. It might seem obvious that they don't, but it's not something everyone realizes. As for the generator case, there are a lot of ways a generator might not be GC'ed at all, and a lot of ways a generator or coroutine might accidentally yield after GeneratorExit even if it doesn't catch the GeneratorExit, for example if an async with suspends a coroutine in __exit__.
@user2357112 yeah - I've been trying for decades to get devs to clean up temp files etc. on app startup, not exit. Relying on the so-called 'clean up and graceful termination', is asking for disappointment and tears:)

wim · Accepted Answer · 2023-01-11 19:29:44Z

Yes. Finally always wins.

The only way to defeat it is to halt execution before finally: gets a chance to execute (e.g. crash the interpreter, turn off your computer, suspend a generator forever).

I imagine there are other scenarios I haven't thought of.

Here are a couple more you may not have thought about:

def foo(): # finally always wins try: return 1 finally: return 2 def bar(): # even if he has to eat an unhandled exception, finally wins try: raise Exception('boom') finally: return 'no boom'

Depending on how you quit the interpreter, sometimes you can "cancel" finally, but not like this:

>>> import sys >>> try: ... sys.exit() ... finally: ... print('finally wins!') ... finally wins! $

Using the precarious os._exit (this falls under "crash the interpreter" in my opinion):

>>> import os >>> try: ... os._exit(1) ... finally: ... print('finally!') ... $

I'm currently running this code, to test if finally will still execute after the heat death of the universe:

try: while True: sleep(1) finally: print('done')

However, I'm still waiting on the result, so check back here later.

finally in a generator or coroutine can quite easily fail to execute, without going anywhere near a "crash the interpreter" condition.
After the heat death of the universe time ceases to exist, so sleep(1) would definitely result in undefined behaviour. :-D
@StevenVascellaro I don't think that's necessary - os._exit is, for all practical purposes, the same as inducing a crash (unclean exit). The correct way to exit is sys.exit.
@wim Do you have any updates regarding the While loop? :P Thanks for the answer, the examples were helpful to me

Stevoisiak · Accepted Answer · 2018-03-13 19:25:49Z

According to the Python documentation:

No matter what happened previously, the final-block is executed once the code block is complete and any raised exceptions handled. Even if there's an error in an exception handler or the else-block and a new exception is raised, the code in the final-block is still run.

It should also be noted that if there are multiple return statements, including one in the finally block, then the finally block return is the only one that will execute.

Serge Ballesta · Accepted Answer · 2018-03-14 07:37:50Z

Well, yes and no.

What is guaranteed is that Python will always try to execute the finally block. In the case where you return from the block or raise an uncaught exception, the finally block is executed just before actually returning or raising the exception.

(what you could have controlled yourself by simply running the code in your question)

The only case I can imagine where the finally block will not be executed is when the Python interpretor itself crashes for example inside C code or because of power outage.

I think "Well, yes and no" is most correct. Finally: always wins where "always" means the interpreter is able to run and the code for the "finally:" is still available, and "wins" is defined as the interpreter will try to run the finally: block and it will succeed. That's the "Yes" and it is very conditional. "No" is all the ways the interpreter might stop before "finally:"- power failure, hardware failure, kill -9 aimed at the interpreter, errors in the interpreter or code it depends on, other ways to hang the interpreter. And ways to hang inside the "finally:".

Blair Houghton · Accepted Answer · 2019-03-30 14:03:58Z

I found this one without using a generator function:

import multiprocessing import time def fun(arg): try: print("tried " + str(arg)) time.sleep(arg) finally: print("finally cleaned up " + str(arg)) return foo list = [1, 2, 3] multiprocessing.Pool().map(fun, list)

The sleep can be any code that might run for inconsistent amounts of time.

What appears to be happening here is that the first parallel process to finish leaves the try block successfully, but then attempts to return from the function a value (foo) that hasn't been defined anywhere, which causes an exception. That exception kills the map without allowing the other processes to reach their finally blocks.

Also, if you add the line bar = bazz just after the sleep() call in the try block. Then the first process to reach that line throws an exception (because bazz isn't defined), which causes its own finally block to be run, but then kills the map, causing the other try blocks to disappear without reaching their finally blocks, and the first process not to reach its return statement, either.

What this means for Python multiprocessing is that you can't trust the exception-handling mechanism to clean up resources in all processes if even one of the processes can have an exception. Additional signal handling or managing the resources outside the multiprocessing map call would be necessary.

Brian Tompsett - 汤莱恩 · Accepted Answer · 2023-06-18 08:24:21Z

You can use a finally with an if statement, below example is checking for network connection and if its connected it will run the finally block

try: reader1, writer1 = loop.run_until_complete(self.init_socket(loop)) x = 'connected' except: print("can't connect server transfer") #open popup x = 'failed' finally : if x == 'connected': with open('text_file1.txt', "r") as f: file_lines = eval(str(f.read())) else: print("not connected")

Collectives™ on Stack Overflow

Does 'finally' always execute in Python?

6 Answers 6

19 Comments

7 Comments

Comments

2 Comments

Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

6 Answers 6

19 Comments

7 Comments

Comments

2 Comments

Comments

Comments

Linked

Related