Exceptions, and the Failures Worth Handling

By the end of this lesson you can wrap the smallest possible block in a handler for one specific exception, respond in a way that helps the person reading the output, and explain why catching everything is worse than catching nothing.

Two failures look identical from outside and deserve opposite treatment. "This record's amount is unparseable" is expected: batches contain bad rows, and one bad row should not end a run over four hundred. "I misspelled a field name" is a defect, and hiding it means shipping a program that reports "no matches" forever while a reviewer wonders why.

The difference is not in the exception; it is in your intent. Handling has to be narrow enough to express that intent, which is why "catch everything, log nothing" is the single most damaging pattern in beginner and generated code alike.

try: runs a block. A matching except SomeError: handles an exception from that block of the named type or a subclass. else: runs when the block finishes normally, without an exception or an early return, break or continue. During ordinary Python execution, finally: runs as control leaves the statement, including on an exception or early return, and is where cleanup belongs.

Four rules make handling useful rather than decorative.

Catch a specific type. except ValueError: says what you expected. except Exception: catches many ordinary exceptions, potentially hiding your own programming mistakes. It does not catch KeyboardInterrupt or SystemExit; a bare except: catches those too when they arise inside its protected block, so a program can become hard to stop.

Wrap the smallest block. Put only the line that can fail inside the try. A ten-line try catches failures from nine lines you were not thinking about, and attributes them to the one you were.

Respond, do not just continue. A handler that only says pass converts a failure into silence. At minimum record what was skipped and why, so a run can report "382 processed, 4 skipped" rather than pretending nothing happened.

Raise when you cannot proceed. raise ValueError(f"unparseable amount: {raw!r}") interrupts normal execution at the bad value and looks for a matching handler, with the value in the message. If no handler catches it, the error propagates out to the runner. That is far kinder than returning a plausible default that fails three functions later.

Two supporting tools. assert condition, "message" states something you believe must always be true; it is a development aid, not input validation, because Python can be run with assertions disabled. And !r inside an f-string uses the value's repr, which shows quotes and whitespace, so '' and ' ' look different in the message.

One safety note for error messages: they end up in logs, screenshots, and support tickets. Name the field and the shape of the problem; do not paste an entire record, and never include a credential.

def parse_value(raw):
    """Return the amount as an int. Raise ValueError naming the field
    when the text cannot be parsed."""
    try:
        return int(raw)
    except ValueError:
        raise ValueError(f"estimated_value is not a whole number: {raw!r}")


def total_value(batch):
    """Return (total, skipped). Bad rows are skipped, not fatal."""
    total = 0
    skipped = []
    for record in batch:
        try:
            total += parse_value(record["estimated_value"])
        except ValueError as error:
            skipped.append((record["notice_id"], str(error)))
    return total, skipped


batch = [
    {"notice_id": "A-1", "estimated_value": "310000"},
    {"notice_id": "A-2", "estimated_value": "96,500"},
    {"notice_id": "A-3", "estimated_value": "180000"},
]

total, skipped = total_value(batch)
print(total)
print(len(skipped), "skipped")
for notice_id, message in skipped:
    print(notice_id, message)

Two layers, doing different jobs. parse_value converts one value and, when it cannot, raises an error that names the field and shows the offending text. It does not decide what the program should do about it, because it cannot know.

total_value makes that decision: one unparseable amount should not abandon the batch, so it records the identifier and the message and carries on. The try wraps exactly one statement, and the caller gets both the total and an honest account of what was left out.

Predict every printed line.

490000
1 skipped
A-2 estimated_value is not a whole number: '96,500'

In total_value, change except ValueError as error: to except Exception: with a body of only pass, and change the first record's key from estimated_value to estimatedValue.

An assistant was asked to make the parser resilient. It produced this and said invalid amounts now default to zero.

def parse_value(raw):
    try:
        return int(raw)
    except:
        return 0


batch = [
    {"notice_id": "A-1", "estimated_value": "310000"},
    {"notice_id": "A-2", "estimated_value": "to be determined"},
]

total = 0
for record in batch:
    total += parse_value(record["estimated_value"])

average = total / len(batch)
print(f"average {average:,.0f}")

Write a conversion that reports its failures instead of raising them, and run it over four differently broken inputs.

Loading this exercise…

Optional: extend parse_amount to accept "96,500" by removing thousands separators before converting, and keep rejecting "to be determined". Then write one sentence on why that change belongs in a normalisation step rather than inside the exception handler. Deciding what to repair and what to report is the judgement the capstone's validation phase is built on.

Sign in to track your progress on this exercise.

1. Why is except ValueError: better than except Exception: when parsing a number?
2. What is wrong with a handler whose body is only pass?
3. When should code raise rather than return a default?
4. What does !r add to a value in an error message?

Sign in to track your progress on this exercise.

Catch one type, wrap one statement, always leave a record of what was skipped, raise with the offending value in the message, and treat zero as a claim rather than a neutral default. Next: writing the tests that prove all of this still holds tomorrow, including a regression test for a bug you have just repaired.