Exercises — Exception handling — try, except (specific), else, finally

Trace the rules. try runs top to bottom: prints A, computes 10/2 = 5.0 (no error), prints B. The try finished with no exception, so by rule 4 the else runs → prints D. The except does not run (nothing was raised). By rule 5 finally always runs → prints E. Output:

A
B
D
E

try prints A, then 10 / 0 raises ZeroDivisionError. By rule 1, everything after it in try is skipped — so B is never printed. By rule 2, the except ZeroDivisionError matches → prints C. Because an exception occurred, the else is skipped (rule 4). finally always runs → prints E. Output:

A
C
E

True. A tuple of exception types means "catch any of these with this one block". It is exactly equivalent to isinstance(error, (ValueError, KeyError)). It does not mean "catch a ValueError and a KeyError at once" (only one exception is ever in flight).

def safe_divide(a, b):
    try:
        result = a / b        # the only risky line
    except ZeroDivisionError:
        return "undefined"
    else:
        return result         # return only when the division succeeded

Why else? So the return result sits outside the protected region — if returning ever misbehaved it would not be swallowed by our except. Keeps the guarded area minimal. Checks: safe_divide(6, 2) == 3.0, safe_divide(5, 0) == "undefined".

A missing dict key raises KeyError, so catch exactly that (not a bare except, not Exception).

def get_item(d, key):
    try:
        return d[key]
    except KeyError:
        return -1

Why this works: d[key] is the only line that can raise on a missing key, and it raises precisely a KeyError — so except KeyError is the narrowest net that still catches the failure we care about. Any other error (say a typo that produced a NameError) is not a KeyError, so it propagates and surfaces the real bug instead of being masked as -1. Checks: get_item({"a": 5}, "a") == 5, get_item({"a": 5}, "z") == -1.

int("oops") raises ValueError. Guard the parse, return double on success.

def parse_and_double(s):
    try:
        n = int(s)
    except ValueError:
        return 0
    else:
        return 2 * n

Why this works: only int(s) can fail on bad input, and it fails with a ValueError, so that is the exact clause type to catch. The doubling 2 * n is not risky, so it belongs in else — this keeps the guarded region to the single parse line, meaning an unrelated bug in the arithmetic could never be swallowed as 0. A leading - like "-4" is a valid integer to int, so it parses fine and doubles to -8. Checks: parse_and_double("21") == 42, parse_and_double("hi") == 0, parse_and_double("-4") == -8.

[1,2,3][99] raises IndexError. By rule 2, Python scans clauses top to bottom and runs the first match. Here the first clause's ClauseType is LookupError, and isinstance(IndexError instance, LookupError) is True (an IndexError is a LookupError), so the first clause matches → prints lookup. The second clause is unreachable — the parent shadowed the child. Output: lookup.

The figure below shows the same idea as two "nets". What the picture shows (in words, for non-visual readers): on the left, the red IndexError falls downward; the first clause except LookupError is drawn as a wide blue net placed above the second net, so the falling error is caught there immediately (labelled "MATCH: isinstance(IndexError, LookupError) = True"). The lower gray net except IndexError is drawn dashed and labelled "unreachable — shadowed": the error never reaches it. On the right is the fix — the specific orange net except IndexError is now on top and catches the error, while except LookupError sits below it and stays reachable for other lookup errors like KeyError. The moral: whichever net is higher (listed first) catches first.

The try executes return "try" — control is about to leave, but by rule 5 finally must run before control leaves. The finally block itself does return "finally", which overrides the pending return. A return in finally wins over any earlier return. Output: finally. (This is a known footgun — return inside finally silently discards the try/except return value and any in-flight exception.)

Put the child first, parent last (rule of thumb from the parent note):

try:
    [1, 2, 3][99]
except IndexError:
    print("index")
except LookupError:
    print("lookup")

Now IndexError matches the first (specific) clause → prints index. A different LookupError such as a KeyError would fall through to the second clause. Both are now reachable. Output: index.

The subtlety: open and read raise different errors, and only read needs the file to be closed afterward. We nest so each guard is minimal, and use finally for the universal log.

def read_report(path):
    try:
        f = open(path)                 # risky #1
    except FileNotFoundError:
        return "missing"
    else:
        try:
            return f.read()            # risky #2, only if open succeeded
        except UnicodeDecodeError:
            return "corrupt"
        finally:
            f.close()                  # close iff we actually opened it
    finally:
        print("attempted")             # ALWAYS, opened or not

Why the structure?

• open alone sits in the outer try — if it fails we never got a file, so there is nothing to close.
• read sits in the else (open succeeded) with its own inner try/finally so the file is closed no matter how the read ends.
• The outer finally prints "attempted" for every path, including the FileNotFoundError return, satisfying "always record the attempt". Note by rule 5 it runs even though the branches return.

Concrete trace — the missing-file path (shows the outer finally firing). Call read_report("nope.txt") on a file that does not exist:

1. open("nope.txt") raises FileNotFoundError.
2. The outer except FileNotFoundError matches → prepares to return "missing".
3. Control is about to leave the construct, so by rule 5 the outer finally runs first → prints attempted.
4. The return "missing" completes.

Printed: attempted. Returned: "missing". This is the demonstration that the outer finally fires even on the early except return — the next exercise traces the read-failure path.

(In real code you'd write with open(path) as f: — see Context managers — with statement and __enter__/__exit__ — which replaces the inner try/finally with the automatic __exit__ close. See also File handling in Python.)

1. open succeeds → into the else.
2. Inner try: f.read() raises UnicodeDecodeError.
3. Inner except matches → prepares to return "corrupt".
4. Inner finally runs first (rule 5): f.close().
5. Control is leaving the outer construct, so the outer finally runs: prints "attempted".
6. The return "corrupt" completes.

Printed: attempted. Returned: "corrupt".

check(50): 50 > 100 is False, so no raise; the try reaches return n → returns 50. check(150): 150 > 100 is True → raise TooBig("over limit"). The clause's ClauseType is ValueError, and TooBig is defined as a subclass of ValueError, so isinstance(TooBig(...), ValueError) is True (rule 2) → the clause matches and runs. Inside it, type(e).__name__ reads the actual runtime class of the caught object, which is "TooBig" (not "ValueError"), so the returned string is "caught TooBig". Returns: check(50) == 50, check(150) == "caught TooBig". Why it catches: an except clause matches the listed class and all its subclasses. Since TooBig inherits from ValueError, any handler written for ValueError also catches every TooBig — this is exactly how custom exceptions slot cleanly into existing handlers.

raise KeyError — but the only clause's ClauseType is IndexError, and KeyError is not an IndexError (they are siblings, both children of LookupError, neither is the other). No clause matches → by rule 3 the KeyError propagates outward. But rule 5 still applies: finally runs before the exception leaves the function → prints cleanup. Then the KeyError continues propagating; if nobody up the stack catches it, the program crashes with a traceback (see Debugging and tracebacks). Result: prints cleanup, then raises KeyError out of g(). The else-style "handled" path is never taken.

Step by step, applying the "only one in-flight exception" idea:

1. try raises ValueError("first") → this becomes the in-flight exception.
2. Python scans clauses; except ValueError matches (rule 2), so its body starts running. The ValueError is now considered being handled.
3. Inside that body we raise RuntimeError("second"). This is a new exception raised while handling the old one, so it replaces the ValueError as the in-flight exception. Python does not re-try the other except clauses of this same construct for the new error — it is now propagating out.
4. Rule 5: before control leaves h(), the finally runs → prints finally ran. (Note: the finally does not catch or suppress anything; it just runs on the way out.)
5. The RuntimeError propagates out of h(). Because it arose during handling, Python chains the original ValueError as its __context__, and the traceback reads "During handling of the above exception (ValueError), another exception occurred".

Result: prints finally ran, then the exception that leaves h() is the RuntimeError (with the ValueError chained as context). The original ValueError is not what propagates — it was replaced. Why: a raise inside an except is a fresh error event; the handler did not finish "handling" quietly, so control does not fall through to normal flow — the new exception takes over.

1. try raises ValueError("original"). There is no except, so this ValueError is in flight and about to leave the function — but rule 5 says finally must run first.
2. The finally body runs and itself does raise RuntimeError("in finally"). This is a new exception raised during cleanup, so it overrides the in-flight ValueError — exactly the same replacement rule as L5.3, but now triggered from finally.
3. What leaves k() is the RuntimeError, with the ValueError kept as its chained __context__ (traceback: "During handling of the above exception, another occurred").

Result: the exception propagating out of k() is the RuntimeError("in finally"); the original ValueError is suppressed as the propagating error (preserved only as context). Why this matters: a bug in your cleanup code can mask the real error the try was trying to report. This is exactly why you keep finally blocks tiny and non-risky — an exception (or return) in finally silently overrides whatever the try/except was going to do (compare L3.2, where a return in finally overrode a pending return; here a raise in finally overrides a pending raise).