Exercises — Raising exceptions — raise, custom exception classes

• (a) Throws a ValueError instance whose .args is ("bad",). str(e) → "bad".
• (b) Throws a ValueError; Python instantiates the class with no args, so .args is () and str(e) is "".
• (c) Builds an exception object and immediately throws it away. Nothing is raised. No error, no effect.
• (d) Returns the object to the caller as an ordinary value. Nothing is raised. The caller receives an exception object and keeps going.

Only (a) and (b) actually raise. Make ≠ raise.

KeyError → LookupError → Exception → BaseException → object. So type(e).__mro__ is (KeyError, LookupError, Exception, BaseException, object) and index 1 is LookupError. The class at the top we must never inherit from directly is ==BaseException== (see Exception Hierarchy & BaseException).

def withdraw(balance, amount):
    if amount < 0:
        raise ValueError("amount must be non-negative")
    if amount > balance:
        raise ValueError("insufficient funds")
    return balance - amount

• withdraw(100, 30) → returns 70 (valid path).
• withdraw(100, -5) → raises ValueError("amount must be non-negative").
• withdraw(100, 150) → raises ValueError("insufficient funds").

Why raise instead of returning -1? Returning a fake number lets the caller keep spending money that isn't there. Raising forces a decision (see the parent's withdraw intuition).

a raises. b has no try, so the exception skips the rest of b and rises. c's try catches it in the except ValueError block. Output:

caught: boom
done

The exception lands at the first matching except walking up the call stack (see Try-Except-Finally).

Output:

args: (50, 80)
shortfall: 30

Here's the subtle bug: because __init__ accepts positional arguments and never calls super().__init__(...), Python's default BaseException.__init__ still captured those positional args, so .args becomes (50, 80) — a confusing pair, not a readable sentence. str(e) then prints "(50, 80)", which looks like data, not a message. The custom attribute e.shortfall still works (80 - 50 = 30) because that code ran. Fix: call super().__init__(f"tried {requested}, only {balance} available") explicitly so .args holds one clean message string instead of the raw constructor arguments (see Classes and __init__).

• Block A: caught, prints A caught. An except catches the named class and all its subclasses. ZeroDivisionError is a ArithmeticError, so the parent-class handler catches it.
• Block B: not caught. ZeroDivisionError is not a ValueError (different branch of the tree). The exception escapes and would print a traceback / crash.

Rule: an except X catches X and everything below X in the hierarchy — nothing above, nothing sideways. The figure below turns this into a picture: ↓

class ConfigError(Exception):
    pass
 
def parse_port(text):
    try:
        return int(text)
    except ValueError as e:
        raise ConfigError(f"bad port: {text!r}") from e

Checking the chain:

try:
    parse_port("abc")
except ConfigError as err:
    print(type(err).__name__)              # ConfigError
    print(str(err))                         # bad port: 'abc'
    print(type(err.__cause__).__name__)     # ValueError

Output:

ConfigError
bad port: 'abc'
ValueError

raise ... from e sets err.__cause__ = e, so the traceback shows "The above exception was the direct cause..." — the low-level ValueError stays visible while the caller catches the friendly ConfigError.

The blank is a bare raise:

    except IOError:
        log("disk problem")
        raise            # re-raise the current exception, keep original traceback

After run():

• messages == ["disk problem"] (exactly one entry — logged once).
• The IOError("disk gone") still propagates out of run(), so a caller must handle it or the program crashes.

A bare raise inside an except re-throws the exception currently being handled with its traceback intact — perfect for "peek, log, then pass it on" (see Logging in Python).

• Block P (implicit): because a RuntimeError was raised while a ValueError was being handled, Python automatically records the old one in err.__context__. So err.__context__ is the ValueError, but err.__cause__ is None. The traceback prints "During handling of the above exception, another exception occurred."
• Block Q (explicit): raise ... from e sets err.__cause__ to the ValueError and err.__context__ is also set to it. The traceback prints the stronger "The above exception was the direct cause of the following exception."

The difference in one line: __context__ is set for you whenever one exception interrupts the handling of another (implicit chaining); __cause__ is set by you with from to declare "this was deliberately caused by that" (explicit chaining). To hide an accidental context you can write raise RuntimeError(...) from None, which sets __cause__ = None and suppresses the context in the printout.

class BankError(Exception):
    """Base for all banking errors."""
    pass
 
class InsufficientFundsError(BankError):
    def __init__(self, balance, requested):
        self.balance = balance
        self.requested = requested
        self.shortfall = requested - balance
        super().__init__(
            f"tried {requested}, only {balance} available (short {self.shortfall})"
        )
 
def withdraw(balance, amount):
    if amount > balance:
        raise InsufficientFundsError(balance, amount)
    return balance - amount
 
try:
    withdraw(50, 80)
except BankError as e:                 # base class catches the subclass
    print("caught:", e)
    print("shortfall:", e.shortfall)

Output:

caught: tried 80, only 50 available (short 30)
shortfall: 30

Why a base class? Catching BankError handles every banking error in one net, while callers who care about the specific case can still write except InsufficientFundsError. The subclass is caught by the base because except X catches all subclasses of X. The figure below draws this family and the single catch-all net: ↓

Use the assert statement: assert amount >= 0, "amount must be non-negative".

• It is syntactic sugar for "if the condition is false, raise AssertionError(msg)."
• It is meant for internal invariants / bugs, not for validating user input.
• Crucially, Python can strip all asserts when run with -O (optimised mode) — so asserts are not guaranteed to run in production.

Contrast: raise ValueError(...) always runs and is the right choice for untrusted input (a user typing a negative amount). assert is for "this should be impossible if my code is correct" checks you're willing to disable in production.

Rule of thumb: validate input with raise; check your own assumptions with assert.

raise vs return? return when there's a meaningful answer; raise when continuing would mean a bug or invalid state.

except Parent catch Child exceptions? Yes — an except catches the named class and all its subclasses (but never siblings or ancestors).

__cause__ vs __context__? __context__ is set automatically when one exception is raised while another is being handled (implicit chaining). __cause__ is set by you with raise B from A to declare a deliberate cause (explicit chaining). raise B from None suppresses the printed context.

raise vs raise e vs raise X from e? Bare raise re-throws the current exception with original traceback. raise e re-throws but resets the traceback to this line (usually undesirable). raise X from e translates to a new type while chaining the cause via __cause__.