Lesson 14: One Bad Line Can Crash Your Whole Program

Introduction

Every developer eventually ships code that meets input it wasn't expecting. A user uploads a file that doesn't exist. A config value that should be a number arrives as a string. A network call that usually succeeds just... doesn't, this one time. None of these are exotic scenarios — they're Tuesday. The question isn't whether your program will encounter bad input, it's whether it has a plan for when it does.

This matters far beyond personal projects. In coding interviews, exception handling is one of the fastest ways to separate a candidate who writes code that "works on the happy path" from one who writes code that survives contact with reality. Interviewers routinely probe this with questions like "what happens if this list is empty?" or "how would you handle a missing key here?" If your answer is a shrug, that's a signal. If your answer is "I'd catch that specific exception and handle it explicitly," that's a very different signal.

Learning try/except/else/finally well is also one of those rare topics in Python where understanding it deeply pays off immediately — it changes how you read tracebacks, how you structure functions that touch files or networks, and how you reason about what "correct" even means when things go wrong.

Problem Overview

Here's the situation in plain terms: Python code executes top to bottom, line by line. If any line raises an exception — an error condition Python detects at runtime — and nothing is there to catch it, the program stops immediately. Every line after the failure point never runs. The user sees a traceback: a wall of red text that means nothing to someone who isn't debugging the code themselves.

The goal is to build a mechanism where:

1. Risky code (file access, type conversion, division, dictionary lookups) is clearly marked as risky.
2. When something goes wrong inside that risky code, you catch the specific problem instead of letting the whole program die.
3. Code that should only run after success has a dedicated place to live.
4. Cleanup code — closing files, releasing connections — runs no matter what happened, success or failure.

Python solves this with four keywords: try, except, else, and finally. You don't need all four in every block, but understanding what each one guarantees is what lets you reason correctly about your program's behavior under failure.

Example

Consider a small function that reads a user's age from input and validates it:

def get_age(raw_value):
    age = int(raw_value)
    if age < 0:
        raise ValueError("age cannot be negative")
    return age

print(get_age("25"))     # works fine -> 25
print(get_age("hello"))  # crashes the whole program
print(get_age("-3"))     # never even runs

Run this, and the moment get_age("hello") executes, int("hello") raises a ValueError. Python has no instructions for what to do next, so it prints a traceback and exits. The third call, get_age("-3"), never gets a chance to run — not because it's wrong, but because the program already died one line earlier.

Now compare that to a version with exception handling:

def get_age(raw_value):
    try:
        age = int(raw_value)
    except ValueError:
        print(f"'{raw_value}' is not a valid number")
        return None
    else:
        if age < 0:
            print("age cannot be negative")
            return None
        return age

for value in ["25", "hello", "-3"]:
    print(get_age(value))

Output:

25
'hello' is not a valid number
None
age cannot be negative
None

Every input gets processed. The bad ones produce a clear message instead of a crash, and the loop keeps going. That's the entire point.

Intuition

Here's how an experienced engineer actually thinks about this, before writing a single line of try/except.

Picture a tightrope walker. The walk itself — the risky part — is the try block. It might go fine. It might not. If the walker falls, there's a safety net underneath: that's the except block, waiting specifically for a fall, not for anything else that could happen in the building. If the walk succeeds without incident, the crowd cheers — that's else, code that should only run when nothing went wrong. And no matter what happened, fall or no fall, the crew rolls up the mats afterward. That's finally. It always runs.

The key intuition experienced engineers rely on: an exception is not a bug report, it's a named event. ValueError, TypeError, KeyError, IndexError — each name tells you exactly what kind of thing went wrong. That naming is the whole reason exception handling is more powerful than a generic "something failed" flag. When you catch ValueError specifically, you're saying "I anticipated exactly this failure mode, and I know what to do about it." When you catch everything with a bare except, you're saying "I have no idea what might go wrong, so I'll hide all of it" — which also means hiding your own typos and logic errors alongside the failure you actually expected.

The second intuition: Python culture favors asking forgiveness rather than permission (EAFP) over checking first (LBYL). You could check if key in dictionary before accessing it, or you could just try the access and catch KeyError if it's missing. For file and network operations especially, checking first doesn't even guarantee success a moment later — the file could be deleted, the connection could drop, between your check and your action. Trying the operation and catching the specific failure is usually the more honest, more reliable pattern.

Brute Force Solution

The "brute force" approach here is really the absence of exception handling, paired with manual pre-checks for every possible failure mode.

Idea: Before doing anything risky, check every condition that could possibly cause a problem.

def get_age_checked(raw_value):
    if not raw_value.lstrip("-").isdigit():
        print(f"'{raw_value}' is not a valid number")
        return None
    age = int(raw_value)
    if age < 0:
        print("age cannot be negative")
        return None
    return age

Advantages:

• No exceptions involved, easy to trace line by line for simple cases.
• Works fine for pure, self-contained validation like this.

Disadvantages:

• Doesn't scale. Every new failure mode needs a new manual check, and it's easy to miss one.
• Breaks down completely for anything involving timing, like files or networks — the state can change between your check and your action (a file can be deleted right after you confirm it exists).
• Duplicates logic that Python's own parsing already knows how to detect (writing your own "is this a valid integer" check is reinventing what int() already does internally).

Complexity: Time O(n) for the string scan in this example, O(1) space. But complexity isn't really the point here — correctness under real-world timing is.

Optimal Solution

The optimal approach is to let Python attempt the risky operation and catch the specific exception it raises, rather than pre-validating everything yourself.

The mental model is a pipeline:

Stage	Runs when	Purpose
try	Always attempted first	Contains the risky code
except SpecificError	Only if that exact exception was raised	Handles one named failure
else	Only if try succeeded with zero exceptions	Code that depends on success
finally	Always, regardless of outcome	Guaranteed cleanup

Python checks except clauses top to bottom and runs the first one that matches the raised exception type. If none match, the exception keeps propagating up the call stack — it does not get silently ignored.

try:
    result = 10 / 0
except ZeroDivisionError:
    print("cannot divide by zero")
except ValueError:
    print("this won't fire, wrong exception type")

Here, only the ZeroDivisionError handler runs, because that's the exception Python actually raised. The order of the except clauses matters only in that Python stops at the first match — so put more specific exceptions before more general ones if there's any overlap.

Python Code

class InvalidAgeError(ValueError):
    """Raised when an age value fails business-rule validation."""


def parse_age(raw_value: str) -> int:
    """
    Convert a raw string into a validated age.

    Raises InvalidAgeError if the value isn't a valid non-negative integer.
    """
    try:
        age = int(raw_value)
    except ValueError as exc:
        raise InvalidAgeError(f"'{raw_value}' is not a valid number") from exc
    else:
        if age < 0:
            raise InvalidAgeError("age cannot be negative")
        return age


def process_ages(raw_values: list[str]) -> list[int]:
    valid_ages = []
    for raw_value in raw_values:
        try:
            age = parse_age(raw_value)
        except InvalidAgeError as exc:
            print(f"Skipping invalid entry: {exc}")
            continue
        else:
            valid_ages.append(age)
        finally:
            print(f"Finished processing '{raw_value}'")
    return valid_ages


if __name__ == "__main__":
    inputs = ["25", "hello", "-3", "42"]
    print(process_ages(inputs))

Code Walkthrough

• class InvalidAgeError(ValueError) — a custom exception that inherits from ValueError. This means it can be caught either as InvalidAgeError specifically, or as ValueError more broadly, giving callers flexibility.
• try: age = int(raw_value) — the only genuinely risky line. int() raises ValueError if the string can't be converted.
• except ValueError as exc: raise InvalidAgeError(...) from exc — catches the specific conversion failure and re-raises it as our own domain-specific exception. The from exc preserves the original traceback for debugging, rather than hiding where the error actually came from.
• else: if age < 0: raise InvalidAgeError(...) — this only runs if the conversion succeeded. Separating "did the conversion work" from "is the value valid" keeps each check honest about what it's testing.
• In process_ages, except InvalidAgeError as exc catches only the exception type we anticipated — a genuine bug elsewhere in the loop body would still surface normally instead of being swallowed.
• finally: print(...) — runs for every single entry, whether it was valid, invalid, or even if something unexpected slipped through. This is the natural place for logging or cleanup that must happen no matter what.

Dry Run

Trace inputs = ["25", "hello", "-3", "42"] through process_ages:

1. "25" → parse_age converts to 25, else checks 25 < 0 is false, returns 25. valid_ages = [25]. finally prints.
2. "hello" → int("hello") raises ValueError → caught, re-raised as InvalidAgeError("'hello' is not a valid number"). Caught in process_ages, prints "Skipping invalid entry: ...". finally still prints.
3. "-3" → converts fine to -3, else branch catches age < 0, raises InvalidAgeError("age cannot be negative"). Caught, skipped, finally prints.
4. "42" → converts fine, 42 < 0 is false, returns 42. valid_ages = [25, 42]. finally prints.

Final output: [25, 42], with four "Finished processing" lines interleaved with the skip messages — proof that finally really does run on every iteration, success or failure.

Complexity Analysis

• Time: O(n) where n is the number of entries in raw_values — each entry is processed exactly once, and exception handling itself adds no meaningful per-call overhead in the success path (Python's exception machinery is essentially free when no exception is raised; the cost is only paid when one actually fires).
• Space: O(k) where k is the number of valid entries, for the valid_ages list being built. No auxiliary data structures scale with input size beyond that.
• These bounds are correct because exception handling changes control flow, not the underlying algorithmic work — you're still doing one pass over the input either way.

Alternative Solutions

LBYL (Look Before You Leap): Check raw_value.lstrip("-").isdigit() before calling int(). This works for pure computation like string parsing where there's no risk of state changing between the check and the action. It's a reasonable style choice here specifically because there's no external resource involved.

Where LBYL breaks down: anything involving files, network calls, or shared state. Checking os.path.exists(path) and then opening the file has a race condition — the file can vanish in between. The EAFP style (try: open(path) and catching FileNotFoundError) is strictly more correct in these cases, because it doesn't assume the world stays still between your check and your action.

Edge Cases

• Empty input: parse_age("") — int("") raises ValueError, correctly caught and converted to InvalidAgeError.
• Whitespace-only input: int(" ") also raises ValueError, handled the same way.
• Exact boundary value: parse_age("0") — zero is a valid, non-negative age, so it should return 0, not be rejected. Worth a dedicated test since 0 is falsy in Python and easy to accidentally mishandle with a careless if age: check instead of if age < 0:.
• Very large numbers: parse_age("99999999999999") — Python integers have no fixed size limit, so this converts fine; any upper-bound validation is a business rule you'd add explicitly, not something Python enforces for you.
• Non-string input types: if raw_value is None or a list, int(raw_value) raises TypeError, not ValueError — and the current code doesn't catch TypeError, so it would propagate up uncaught. This is intentional here to illustrate why matching the exact exception type matters.

Common Mistakes

1. Bare except: with no exception type. This catches everything, including typos in your own code (NameError from a misspelled variable), and hides them right alongside the error you meant to catch.
2. Catching the generic Exception class as a habit. It technically works, but a network timeout and a typo in your code get the exact same vague error message, making debugging much harder later.
3. Using except and pass together with nothing else. This silently swallows failures with zero trace that anything went wrong — the program appears to work while quietly doing the wrong thing.
4. Putting too much code inside the try block. If five lines are inside try and only one of them can actually raise the exception you're catching, you risk masking failures from the other four lines under the same handler.
5. Forgetting that else only runs after zero exceptions. Some developers put post-success code directly after the except block instead of in else, which means it also runs even when an exception was caught but didn't cause a return.
6. Using finally for logic that should only happen on success or only on failure. finally runs unconditionally — it's for cleanup, not conditional business logic.
7. Catching an exception without re-raising or logging it when the caller genuinely needs to know. Swallowing an error you don't actually know how to handle just relocates the bug somewhere harder to find.

Interview Questions

• What's the difference between except Exception and a bare except:?
• When would you use else instead of just putting code at the end of the try block?
• Explain EAFP versus LBYL — when would you choose one over the other?
• Does finally run if the function returns from inside the try block? What if it returns from inside except?
• How would you design a custom exception hierarchy for a small application?
• What happens if an exception is raised inside a finally block?
• Why is catching overly broad exception types considered risky in production code?

Similar Problems

• LeetCode-style input validation problems (e.g., parsing malformed strings to integers) — same core skill: catching ValueError from int()/float() conversions.
• File I/O problems involving FileNotFoundError and PermissionError — reinforce the EAFP pattern with real system resources instead of pure computation.
• Dictionary/lookup-heavy problems using .get() versus direct indexing with KeyError — a close cousin of this lesson, since .get() is essentially LBYL and try/except on direct access is EAFP.
• Custom exception design problems in larger take-home assignments — extending this lesson's InvalidAgeError pattern to build a full exception hierarchy for a domain.

Key Takeaways

try holds the risky code. except catches a specific, named failure — never catch more broadly than you understand. else runs only when the try block succeeded completely, keeping success-path logic cleanly separated from the risky part. finally always runs, making it the right home for cleanup work like closing files or connections. You can also raise your own exceptions to enforce rules specific to your program, turning "invalid data" into a named, catchable event instead of a silent bug. Master this pattern, and your code stops crashing on bad input and starts handling problems the way production software actually needs to.

Watch the Video

This lesson is easier to absorb watching the flow play out step by step — catch the full walkthrough here: {LINK}

About the Series

This lesson is part of Fun with Learning Technology, a series built around one idea: the concepts that trip up developers the most — exceptions, recursion, closures, generators — are almost always simple once you see the right mental model. Each lesson builds on the last, so if exception handling clicked for you here, the rest of the series is designed to keep that momentum going.

Call To Action

If this lesson made try/except click for you, the video has the full walkthrough with live code — give it a like and subscribe on YouTube so future lessons land in your feed automatically. For deeper dives and written breakdowns like this one, subscribe to the Substack. And if you've got a war story about a bare except: that hid a bug for way too long, drop it in the comments — those stories are usually the best teachers. Sharing this with a developer who's still fighting scary tracebacks helps the series reach more people who need it.

---

try:
    result = 10 / 0
except ZeroDivisionError:
    print("Cannot divide by zero")
except ValueError:
    print("Bad value given")