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?
Best Answer
"Guaranteed" is a much stronger word than any implementation of
finally
deserves. What is guaranteed is that if execution flows out of the wholetry
-finally
construct, it will pass through thefinally
to do so. What is not guaranteed is that execution will flow out of thetry
-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:Note that this example is a bit tricky: when the generator is garbage collected, Python attempts to run the
finally
block by throwing in aGeneratorExit
exception, but here we catch that exception and thenyield
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
await
s in__aexit__
, or if the objectawait
s oryield
s in afinally
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 executingfinally
blocks.os.fork
may causefinally
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 callsos._exit
in the worker once the worker's job is done,finally
andmultiprocessing
interaction can be problematic (example).finally
blocks from running.kill -SIGKILL
will preventfinally
blocks from running.SIGTERM
andSIGHUP
will also preventfinally
blocks from running unless you install a handler to control the shutdown yourself; by default, Python does not handleSIGTERM
orSIGHUP
.finally
can prevent cleanup from completing. One particularly noteworthy case is if the user hits control-C just as we're starting to execute thefinally
block. Python will raise aKeyboardInterrupt
and skip every line of thefinally
block's contents. (KeyboardInterrupt
-safe code is very hard to write).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 onfinally
for too much.