Error Handling Basics

Core lesson 01

Prefer except Exception (or a specific type) over a bare except: — bare except also swallows KeyboardInterrupt and SystemExit.

Python's exception hierarchy has BaseException at the root, with Exception as one major branch and things like SystemExit and KeyboardInterrupt as siblings, not children, of Exception. A bare `except:` catches everything under BaseException, including those control-flow signals — which means Ctrl+C might get silently swallowed by an overly broad except block. `except Exception:` catches ordinary errors while letting those system-level signals propagate as intended.

try:
    result = 10 / 0
except Exception as e:
    print(f"Handled: {type(e).__name__}: {e}")

# avoid this pattern:
# try:
#     ...
# except:
#     pass   # hides real bugs AND Ctrl+C

Core lesson 02

finally always runs — success, exception, or even a return in try/except — making it the right place for guaranteed cleanup.

`finally` is Python's guarantee: whatever happens inside the `try`/`except` above it — normal completion, an exception, or even a `return`/`break` — the `finally` block still executes before control actually leaves. This makes it the correct place for cleanup that must happen no matter what, like releasing a lock or closing a file (though a `with` context manager is usually cleaner for that specific case).

def read_value(d, key):
    print("attempting lookup")
    try:
        return d[key]
    except KeyError:
        return None
    finally:
        print("cleanup always runs")

print(read_value({"a": 1}, "a"))
print(read_value({"a": 1}, "b"))

try:                     Exception flow:
    risky()          ---> raised in risky()
except ValueError:
    handle()      <---- caught here, others propagate up
finally:
    cleanup()   <---- ALWAYS runs, success or failure

Core lesson 03

class MyError(Exception): pass, then raise MyError('message') — subclass Exception (or a more specific built-in) and raise it like any other.

Custom exceptions let calling code catch and handle *your* specific failure modes distinctly from generic errors. You define them by subclassing Exception (or a more specific existing exception if that's semantically closer), optionally adding extra attributes or overriding `__init__` to carry structured error data, not just a message string.

class InsufficientFundsError(Exception):
    def __init__(self, balance, amount):
        super().__init__(f"Cannot withdraw {amount}, balance is {balance}")
        self.balance = balance
        self.amount = amount

def withdraw(balance, amount):
    if amount > balance:
        raise InsufficientFundsError(balance, amount)
    return balance - amount

try:
    withdraw(50, 100)
except InsufficientFundsError as e:
    print(e, "| shortfall:", e.amount - e.balance)

Core lesson 04

It explicitly chains exceptions, showing both the new error and its original cause in the traceback — preserving debugging context instead of hiding it.

When you catch one exception and raise a different, more meaningful one in response, Python still remembers the original by default (as `__context__`) and prints 'During handling of the above exception, another exception occurred'. Using `raise NewError(...) from original` makes that relationship explicit and intentional, changing the message to 'The above exception was the direct cause of the following exception' — clearer for anyone reading the traceback later.

def parse_config(raw):
    try:
        return int(raw)
    except ValueError as e:
        raise RuntimeError(f"invalid config value: {raw!r}") from e

try:
    parse_config("not-a-number")
except RuntimeError as e:
    print(e)
    print("caused by:", e.__cause__)