Exceptions and finally: the one word that stops a function from failing

Base: four parts, each with its own job

A try statement has four parts. Everyone knows the first two; the other two are the ones people mix up — and mixing up their jobs is what produces the errors this whole lesson is about.

• try — the attempt: code that might not work out;
• except — the handling: what to do if it did not, and for which error exactly;
• else — the "no error happened" branch: code that only makes sense when the attempt succeeded;
• finally — the exit taken either way: code that runs after success and after failure alike.

One example shows all four at once:

try:
    value = int(raw)              # the attempt
except ValueError:
    value = 0                     # reached only if the attempt failed
else:
    audit(value)                  # reached only if it succeeded
finally:
    counter += 1                  # reached in either case

finally deserves a sentence of its own, because its job is wider than it looks. It runs not only after a success and after a caught error, but also when control leaves the block outwards: on a return from the middle of the try, and on an error nobody caught. That is why releasing resources — closing a file, releasing a lock — goes in a finally: it is the one place that is known to be reached.

And here is the question this lesson is about. finally runs while the exception is on its way out — so what happens to the exception itself if the finally decides to leave outwards too, with a return, a break or a continue?

Usually nothing unusual: the finally runs and the exception carries on. But in this one case the exception disappears. Not deferred, not replaced: it is gone, and the function returns a value as if nothing had failed.

That is already enough to answer the basic interview question: try is the attempt, except the handling, else the success branch, finally the exit taken either way — and that exit can swallow the error. Everything below is about what that looks like in code nobody would suspect; about how a bare except: differs from except Exception:; and about exception chains and groups, where several errors arrive at once.

Mechanism 1: the one word that stops a function from failing

The reference puts it in a single sentence: “If the finally clause executes a return, break or continue statement, the saved exception is discarded”.

Read “discarded” literally. Not overridden, not replaced — gone:

def never_fails():
    try:
        raise RuntimeError("anything at all")
    finally:
        return None

This function cannot fail. Not ever, not from anything: any exception inside the try is dropped on the way out. Verified by running it: the call returns None, and there is no exception.

break does the same, and it is harder to spot because there is no return in sight:

for _ in range(1):
    try:
        raise KeyError("this one too")
    finally:
        break

The fourth case in the figure is the same return in finally without an exception: what gets discarded there is an ordinary result.

Mechanism 2: the error that does not crash

The rows are the same as in the context-managers lesson. Different mechanism — same wrong answer.

ROWS = [
    {"id": 1, "amount": "100"},
    {"id": 2, "amount": "no data"},      # broken
    {"id": 3, "amount": "50"},
    {"id": 4, "amount": "25"},
]

The right version: finally only closes the resource, and a separate except decides what to do with a broken row.

def correct(rows):
    total = 0
    for row in rows:
        handle = open("/dev/null", "w")
        try:
            total += int(row["amount"])
        except ValueError:
            continue
        finally:
            handle.close()
    return total

The wrong one looks tidier — “we closed the resource and honestly returned what we managed to count”:

def broken(rows):
    total = 0
    for row in rows:
        handle = open("/dev/null", "w")
        try:
            total += int(row["amount"])
        finally:
            handle.close()
            return total          # ← right here

Verified by running it (identical on 3.13.7 and 3.14.7):

75 of 175 lost, not one exception in the log. One line separates the two functions, and that line looks like care for a resource. But a return in finally leaves the function at the first broken row, dropping the exception on the way out — whereas except ValueError: continue in the right version simply moves on to the next record.

Mechanism 3: else — what is it for, if you can just add to try

The difference shows up not in the successful case, but in what happens to an exception raised by the code you added.

The reference: “The optional else clause is executed if the control flow leaves the try suite, no exception was raised… Exceptions in the else clause are not handled by the preceding except clauses”.

So else is the way to narrow the try down to the line that can actually fail:

try:
    value = registry[key]          # may raise KeyError
except KeyError:
    value = default
else:
    audit(value)                   # a KeyError from here is NOT caught

If audit raises a KeyError of its own, the handler will not catch it — and rightly so: this except was written for one specific line, not for whatever happens to sit nearby. Verified by running it: an exception raised in else walks straight past the except above it.

Add a finally to the same block and the order comes out like this (verified by running it):

no exception:   try -> else -> finally
with exception: try -> except -> finally

Mechanism 4: a bare except: catches more than you think

KeyboardInterrupt and SystemExit are not Exception. One line settles it: issubclass(SystemExit, Exception) is False, and the MRO of KeyboardInterrupt is KeyboardInterrupt → BaseException → object.

The documentation explains the design: “The exception inherits from BaseException so as to not be accidentally caught by code that catches Exception and thus prevent the interpreter from exiting”.

That is, the hierarchy is built so that except Exception: lets Ctrl+C through. A bare except: removes that protection: it catches BaseException, and the program no longer exits on Ctrl+C.

Mechanism 5: chains — __context__, __cause__ and from None

An exception raised inside an except gets a reference to the previous one — that is PEP 3134, and the interpreter does it without the author's involvement.

The third row is the useful one. from None does not remove the previous exception: __context__ stays where it was, and only __suppress_context__ changes — the flag that keeps the traceback from printing it.

In practice this means from None is about the readability of a message, not about hiding data. The previous exception remains reachable from the object, and a top-level handler can still log it.

One more detail, this time from the language reference rather than the PEP: the name bound by except … as e is deleted at the end of the clause. The reference gives the exact desugaring — it is as if the body were wrapped in try: … finally: del N. Touching e after the block raises NameError; to keep the object, assign it to another name.

Mechanism 6: groups — how except* differs from except

PEP 654 (3.11) added the ExceptionGroup type and the except* syntax for one job: to raise and handle several independent errors at once. The typical source is parallel tasks that each failed differently. That is exactly what asyncio.TaskGroup reports, and the chain is a direct one:

1. TaskGroup cancels the siblings and collects their errors;
2. it hands them over as one object — an ExceptionGroup holding several independent exceptions;
3. except* splits the group by type, and each branch runs at most once.

TaskGroup itself is covered in the async/await lesson; what is taken apart here is the second half of the chain. Everything below is verified by running it.

A group is an object, not its contents. An ExceptionGroup does not "unwrap" into its errors: a plain except ValueError: will not catch the group, even if there is exactly one ValueError inside.

try:
    raise ExceptionGroup("one", [ValueError("lonely")])
except ValueError:
    print("not here")
except ExceptionGroup as e:
    print("caught the group:", type(e).__name__)   # → caught the group: ExceptionGroup

A plain except Exception does catch the group, but as a whole — as one object, not error by error.

except* splits the group by type and can run several times for one raise. Each clause receives a subgroup — again an ExceptionGroup — with all leaves of its type. The PEP: “a single exception group can cause several except* clauses to execute, but each such clause executes at most once”.

try:
    raise ExceptionGroup("two troubles", [ValueError("value"), KeyError("key")])
except* ValueError as eg:
    print("ValueError:", [str(x) for x in eg.exceptions])   # → ValueError: ['value']
except* KeyError as eg:
    print("KeyError:", [str(x) for x in eg.exceptions])      # → KeyError: ["'key'"]
# both clauses ran for one raise

Note: the clause variable (eg) is not a single exception but a group; the errors themselves are in eg.exceptions.

The unhandled remainder travels on — again as a group. If the clauses did not take everything, the remaining leaves keep propagating as an ExceptionGroup, not as separate exceptions:

try:
    raise ExceptionGroup("three", [ValueError(), KeyError(), TypeError()])
except* ValueError:
    pass
# an ExceptionGroup([KeyError(), TypeError()]) propagates out

You cannot mix except and except* in one try — it is a syntax error. A try's clauses are either all plain or all starred.

Deeper: what a try costs

Now the part that gets argued about without numbers: what the construction itself costs.

Read the columns separately. The builds of 3.13.7 and 3.14.7 differ by more than the compiler, and the gap between columns is not a difference between language versions.

The gap between the first two rows has to be put next to the spread of the instrument before anything is said about it — and the run does that itself, by repeating the whole measurement five times (labels translated from the script's output, the numbers are as printed):

  SPREAD OVER 5 REPEATS OF THE WHOLE MEASUREMENT
  no try                         38.7 ..   39.1 ns  spread   0.4
  try/except, not taken          40.5 ..   40.9 ns  spread   0.4
  try/except, taken             201.1 ..  203.4 ns  spread   2.3

  gap between the first two rows           1.8 ns
  widest spread of those same two rows      0.4 ns
  can the instrument resolve the gap     yes

Resolvable: 1.8 ns against a spread of 0.4. So the claim here is not “indistinguishable” but something narrower and more useful: a try that does not fire costs about two nanoseconds — five percent — and the sign of that difference is stable, with the try version slightly slower in all five repeats.

That changes the question. It is no longer “is there a difference” — there is — but “is it worth anything”, and that is a question about size. Five percent on an empty call pays for no restructuring at all: for it to show up as a win, the try would have to sit in a loop that is itself the bottleneck.

The bytecode shows why. SETUP_FINALLY is documented under pseudo-instructions, and about those the dis page says outright: “They do not appear in Python bytecode. They are used by the compiler but are replaced by real opcodes or removed before bytecode is generated”. Verified with the disassembler on all four versions — SETUP_FINALLY appears in none of them.

Here is what actually executes:

no try:  RESUME     LOAD_NAME  PUSH_NULL  CALL  POP_TOP
in try:  RESUME NOP LOAD_NAME  PUSH_NULL  CALL  POP_TOP

One NOP apart. Where did the handling go? Into a separate table: the disassembler prints it as an ExceptionTable block under the code. While no exception occurs, nobody reads that table.

And here the boundary of the observation matters as much as the number. What was measured is one empty call in a loop, on two CPython builds, on one machine. Exactly one thing follows: in this measurement a try on the successful path costs about two nanoseconds — not that a try is free in general, and not that it can go anywhere without consequence. Nested handlers, a finally with work in it, a try inside a generator are not covered by this measurement.

So the practical conclusion is written from the boundary rather than from the number: the argument “drop the try, it is slowing us down” has nothing behind it — when it comes up, ask for a measurement instead of removing the construction. The expensive case is a taken exception — five times as much — and that is what does not belong in a hot loop as a routine branch.

Deeper: what changed in 3.14

The compiler started warning about a return or a break that leaves a finally. Verified by compiling:

3.11.15   warnings: 0
3.12.3    warnings: 0
3.13.7    warnings: 0
3.14.7    SyntaxWarning: 'return' in a 'finally' block

break gets its own message, 'break' in a 'finally' block.

The behaviour did not change. PEP 765 (Irit Katriel, Alyssa Coghlan) says so directly: “we leave it open whether, and when, this will become a SyntaxError”. Code written this way runs exactly as it did — it is merely reported now. The PEP names the reason for the caution: runs with -We turn warnings into errors, and an immediate ban would break them.

Deeper: version history

How to answer in an interview

The short answer: try is the attempt, except handles the error, else is the "no error happened" branch, finally is the exit taken either way. And the key point about finally: if it transfers control outwards itself — return, break, continue — the exception in flight disappears. The reference puts it in one sentence: "the saved exception is discarded".

That is enough to answer correctly. Beyond it is what you add if the interviewer digs.

If the interviewer digs deeper

First, show what it looks like in real code: a return in finally reads as care for a resource, yet it leaves the function at the very first error; the same rows as in the context-managers lesson yield 100 instead of 175, with not one exception in the log. From 3.14 the compiler warns about it (PEP 765) — and only warns: the behaviour is unchanged.

Second, a bare except: catches BaseException, meaning Ctrl+C and sys.exit() — the hierarchy is built precisely so that except Exception: lets them through.

Third, if the conversation turns to speed, quote the measurement together with its boundary: on the successful path a try costs about two nanoseconds in this measurement (40.5 ns against 38.7 for the same code without the try, a gap of five percent against an instrument spread of 0.4 ns), while a taken exception costs 201.1 ns — five times more. The reason is structural: SETUP_FINALLY is a pseudo-instruction and never reaches the bytecode, so on the happy path try adds a single NOP. The conclusion is narrow: there is no reason to remove a try for speed, and there is a reason not to use exceptions as routine branching in a hot loop.

Next they ask

Common misconceptions

Practice

Two exercises. Answer first, then check against the real output: in both, the right answer comes from a recorded run rather than from an editor.

def swallow():
  try:
      raise ValueError("boom")
  finally:
      return "ok"


def keep():
  try:
      raise ValueError("boom")
  finally:
      pass


print(swallow())
try:
  keep()
except ValueError as e:
  print("ValueError:", e)

ok
ValueError: boom

ValueError: boom
ValueError: boom

ok
ok

Traceback (most recent call last):
ValueError: boom

Knowledge check