Specific Exceptions & Multiple except Blocks

By the end of this lesson you can:

• Stack multiple except blocks under one try — Python jumps to the first matching one.
• Catch several types in one block with a tuple: except (ValueError, TypeError):.
• Use raise SomeError(message) to signal your own problems.
• Know the broad family tree of built-in exceptions so you can pick the right one.

This little snippet has two failure modes. Can you spot both?

raw = input("How many sweets? ")
sweets = int(raw)
each = 100 / sweets
print(f"Each person gets {each} grams.")

try:
    raw = input("How many sweets? ")
    sweets = int(raw)
    each = 100 / sweets
    print(f"Each person gets {each} grams.")
except ValueError:
    print("Please type a number.")
except ZeroDivisionError:
    print("Hmm, can't share zero sweets.")

Pattern 1 · One except per type

try:
    risky()
except ValueError:
    print("Bad value.")
except FileNotFoundError:
    print("Missing file.")
except ZeroDivisionError:
    print("Zero divide.")

Stack as many as you need. The blocks are checked in order; the first one whose type matches the exception runs, and the rest are skipped.

Pattern 2 · Several types in one block

If the response would be identical, group them with a tuple.

try:
    n = int(input("Number: "))
    result = 100 / n
except (ValueError, ZeroDivisionError):
    print("Couldn't compute. Try a non-zero number.")

Note the round brackets — that's a tuple of exception types. Don't write except ValueError, ZeroDivisionError: (no brackets) — that's old Python 2 syntax and will fail in Python 3.

Pattern 3 · The catch-all at the bottom

Use Exception as a generic fallback for "anything else I forgot". Always put it last; otherwise it grabs everything before the specific blocks get a chance.

try:
    risky()
except ValueError:
    print("Bad value.")
except FileNotFoundError:
    print("Missing file.")
except Exception as e:
    print(f"Something else went wrong: {e}")

Catching Exception still lets KeyboardInterrupt through (good) — unlike the bare except: from yesterday.

The order matters · subclasses come first

Some exception types inherit from others. FileNotFoundError is a kind of OSError. If you put OSError first, it'll grab everything and the FileNotFoundError block never runs.

# Right
try:
    open("missing.txt")
except FileNotFoundError:
    print("Not found")
except OSError:
    print("Other disk problem")

# Wrong — FileNotFoundError block is unreachable
try:
    open("missing.txt")
except OSError:
    print("Other disk problem")
except FileNotFoundError:
    print("Not found")     # never runs!

Rule: specific first, general last.

The exception family tree (the bits you'll meet)

BaseException
 └─ Exception
     ├─ ArithmeticError
     │   └─ ZeroDivisionError
     ├─ LookupError
     │   ├─ IndexError
     │   └─ KeyError
     ├─ ValueError
     ├─ TypeError
     └─ OSError
         ├─ FileNotFoundError
         ├─ PermissionError
         └─ IsADirectoryError

You don't need to memorise it — but knowing that FileNotFoundError is a kind of OSError stops the "why isn't my catch running?" bug.

Raising your own

To signal "something's wrong" from your own code, use raise. Pick the right type and write a clear message.

def withdraw(balance, amount):
    if amount <= 0:
        raise ValueError(f"Amount must be positive: {amount}")
    if amount > balance:
        raise ValueError(f"Insufficient funds: balance is {balance}, want {amount}")
    return balance - amount

try:
    new_balance = withdraw(100, -10)
except ValueError as e:
    print(f"Withdrawal failed: {e}")
# → Withdrawal failed: Amount must be positive: -10

Two things to spot. (1) raise SomeError("message") stops the function and the exception bubbles up. (2) Callers catch it with the usual try/except.

try:
    risky()
except ValueError as e:
    log(f"got a ValueError: {e}")
    raise          # ← re-raise — don't swallow it

The story

Build safe_loader.py. It opens a numeric file and computes the average. There are three failure modes; we react differently to each.

1. File missing — print a polite message, exit clean.
2. File present but blank — "no data", exit clean.
3. File has at least one non-numeric line — skip that line, keep going.

Code

# safe_loader.py — file loading with three handled failure modes

def load_numbers(path):
    numbers = []
    skipped = 0
    try:
        with open(path) as f:
            for line in f:
                line = line.strip()
                if line == "":
                    continue
                try:
                    numbers.append(float(line))
                except ValueError:
                    skipped += 1
    except FileNotFoundError:
        raise            # let the caller decide what to do
    except PermissionError as e:
        raise RuntimeError(f"Can't read {path}: {e}")

    return numbers, skipped

try:
    nums, bad = load_numbers("temperatures.txt")
except FileNotFoundError:
    print("No temperatures file yet — nothing to average.")
    raise SystemExit
except RuntimeError as e:
    print(f"Couldn't read the file: {e}")
    raise SystemExit

if len(nums) == 0:
    print("File is empty.")
    raise SystemExit

avg = sum(nums) / len(nums)
print(f"{len(nums)} numbers loaded ({bad} bad lines skipped). Average: {avg:.2f}")

Sample outputs (depending on the file)

# temperatures.txt missing:
No temperatures file yet — nothing to average.

# temperatures.txt = "31\n32\nthirty\n29\n":
3 numbers loaded (1 bad lines skipped). Average: 30.67

# temperatures.txt is empty:
File is empty.

Read the diff

Two layers of try/except — one inside the loader (catches per-line problems, decides to re-raise the file-level ones) and one outside (catches the file-level problems and exits clean). That separation is the right structure for any file-handling code: low-level catches the small stuff and lets the big stuff bubble; the caller's catch makes the big stuff polite.

Multiple except blocks let you react differently to different failure modes. Group with a tuple when responses match. Order specifically-to-generally — a subclass before its parent. Use raise SomeError(message) to signal a problem from your own code; a bare raise inside an except re-throws the current exception. Catch Exception only as a last-resort fallback, never bare except:.