Exception Handling

amounts = ["120.50", "89.99", "not-a-number", "45.00"]

total = 0
for amount in amounts:
    total += float(amount)   # crashes on the third item

print(total)   # never reached — the program already terminated
# ValueError: could not convert string to float: 'not-a-number'

amounts = ["120.50", "89.99", "not-a-number", "45.00"]

total = 0
skipped = 0
for amount in amounts:
    try:
        total += float(amount)
    except ValueError:
        skipped += 1
        print(f"Skipping invalid amount: {amount!r}")

print(f"Total: {total}, skipped: {skipped}")
# Skipping invalid amount: 'not-a-number'
# Total: 255.49, skipped: 1

try:
    result = risky_operation()
except SomeError:
    # runs ONLY if the try block raised SomeError
    handle_the_error()
else:
    # runs ONLY if the try block completed with NO exception at all
    use_the_result(result)
finally:
    # ALWAYS runs — whether an exception occurred, was caught, wasn't caught,
    # or the try block succeeded cleanly. Even if the except block itself
    # raises a new exception, finally still runs before it propagates.
    cleanup()

# Without else — a bug hiding in plain sight
try:
    data = json.loads(text)
    process(data)          # if process() ALSO raises a ValueError, it gets
except ValueError:          # incorrectly caught here too, as if parsing had failed
    print("Invalid JSON")

# With else — only json.loads() failures are caught;
# any error from process() propagates normally, as it should
try:
    data = json.loads(text)
except ValueError:
    print("Invalid JSON")
else:
    process(data)

def process_file(path):
    f = open(path)
    try:
        return risky_parse(f)
    finally:
        f.close()   # runs whether risky_parse() succeeds, raises, or anything in between

# This is conceptually what "with open(path) as f:" does for you automatically —
# which is exactly why "with" is still preferred over writing this by hand.

try:
    process_order(order)
except:
    print("Something went wrong")

# This catches EVERYTHING, including:
# - a genuine bug like a typo: proces_order(order)  (NameError)
# - passing the wrong type entirely: order.total()  (TypeError, if total is not callable)
# - Ctrl+C during a long-running operation (KeyboardInterrupt)
# - the process being asked to exit cleanly (SystemExit)
#
# All of these get reduced to the same unhelpful message,
# and the ORIGINAL bug is now invisible.

try:
    process_order(order)
except (ValueError, KeyError) as e:
    print(f"Order data was invalid: {e}")
    log_error(order, e)

# A genuine bug (NameError, TypeError from your own code) is NOT caught here —
# it propagates normally, with a full traceback, so it gets noticed and fixed
# instead of silently disappearing behind a generic error message.

BaseException
 ├── SystemExit
 ├── KeyboardInterrupt
 └── Exception                 # the class almost everything you catch inherits from
      ├── ValueError            # right type, invalid value — e.g. int("hello")
      ├── TypeError              # operation on the wrong type entirely
      ├── KeyError                # dict key that doesn't exist
      ├── IndexError                # list/sequence index out of range
      ├── AttributeError             # accessing an attribute/method that doesn't exist
      ├── FileNotFoundError            # a subclass of OSError — file doesn't exist
      └── ZeroDivisionError              # division or modulo by zero

try:
    value = int(user_input)
except Exception:
    # catches ValueError, TypeError, and literally any other Exception subclass —
    # broader than you usually want, but still excludes BaseException's other branches
    print("Something went wrong parsing input")

def set_discount(percent):
    if not 0 <= percent <= 100:
        raise ValueError(f"Discount must be between 0 and 100, got {percent}")
    return percent

set_discount(150)
# ValueError: Discount must be between 0 and 100, got 150

def get_user(user_id):
    if not isinstance(user_id, int):
        raise TypeError(f"user_id must be an int, got {type(user_id).__name__}")
    user = database.lookup(user_id)
    if user is None:
        raise KeyError(f"No user found with id {user_id}")
    return user

def process_payment(order):
    try:
        charge_card(order)
    except PaymentError as e:
        log_error(f"Payment failed for order {order.id}: {e}")
        raise   # re-raises the SAME PaymentError — the caller still sees it,
                # and still gets the full original traceback

def load_config(path):
    try:
        with open(path, encoding="utf-8") as f:
            return json.load(f)
    except json.JSONDecodeError as e:
        raise ValueError(f"Config file {path} contains invalid JSON") from e

# The resulting traceback shows both exceptions:
#   json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
#
#   The above exception was the direct cause of the following exception:
#
#   ValueError: Config file settings.json contains invalid JSON

class InsufficientFundsError(Exception):
    """Raised when a withdrawal would take an account below zero."""
    pass

class Account:
    def __init__(self, balance):
        self.balance = balance

    def withdraw(self, amount):
        if amount > self.balance:
            raise InsufficientFundsError(
                f"Cannot withdraw ${amount:.2f} — balance is only ${self.balance:.2f}"
            )
        self.balance -= amount
        return self.balance

account = Account(balance=100)

try:
    account.withdraw(250)
except InsufficientFundsError as e:
    print(f"Transaction declined: {e}")
    notify_customer(account, reason="insufficient_funds")

# Transaction declined: Cannot withdraw $250.00 — balance is only $100.00

class InsufficientFundsError(Exception):
    def __init__(self, requested, available):
        self.requested = requested
        self.available = available
        super().__init__(
            f"Cannot withdraw ${requested:.2f} — balance is only ${available:.2f}"
        )

try:
    account.withdraw(250)
except InsufficientFundsError as e:
    shortfall = e.requested - e.available
    print(f"Short by ${shortfall:.2f}")   # the caller can react to the SPECIFIC numbers,
                                              # not just parse the error message as text

# This:
with open("data.txt") as f:
    process(f)

# Behaves equivalently to this, written by hand:
f = open("data.txt")
try:
    process(f)
finally:
    f.close()

# In both versions, f.close() runs whether process() succeeds,
# raises an exception, or does anything in between.

A scheduling platform's nightly job sends appointment reminder emails to patients. For three weeks, a growing number of patients silently stopped receiving reminders — no alerts fired, no errors appeared in any dashboard, because the job itself reported success every single night.

What the postmortem finds

def send_reminders(appointments):
    sent = 0
    for appt in appointments:
        try:
            send_email(appt.patient_email, build_reminder(appt))
            sent += 1
        except:
            pass   # "just skip anything that fails, don't crash the whole job"
    return sent

The except: was added months earlier, deliberately, to stop one specific transient issue — an occasional email-provider timeout — from crashing the entire nightly batch over a single patient. It worked, in the narrow sense that the job never crashed again. But it also caught everything else that could possibly go wrong inside the loop, forever, with no distinction.

The real bug: a recent change to build_reminder() introduced a KeyError for a small subset of appointments missing a newly-added field. That exception was real, genuinely worth investigating — and the bare except: quietly absorbed it every night, indistinguishable from the harmless timeout it was originally written for.

def send_reminders(appointments):
    sent, failed = 0, 0
    for appt in appointments:
        try:
            send_email(appt.patient_email, build_reminder(appt))
            sent += 1
        except EmailTimeoutError as e:
            failed += 1
            log_error(f"Timed out sending to {appt.patient_email}: {e}")
        # anything else — a KeyError from build_reminder(), a bug, anything unexpected —
        # is no longer caught here at all, and will surface immediately and loudly

    if failed:
        alert_oncall(f"{failed} reminder(s) failed to send")
    return sent

This is the precise cost of the bare except: anti-pattern described in Part 03: it doesn't just risk hiding bugs in the abstract, it genuinely did — for three weeks, in a system where a missed reminder has a real, direct impact on patients. The team's follow-up added a lint rule that flags bare except: and except Exception: without a specific reason comment, enforced in CI going forward.