Error Handling — try / except

By the end of this lesson you can:

• Wrap a risky operation in try: and catch the failure in except:.
• Read a Python traceback — the bottom line tells you the exception type.
• Explain why a bare except: is dangerous, and what to do instead.
• Choose between "look before you leap" (LBYL) and "easier to ask forgiveness" (EAFP).

What happens if the user types banana into this prompt?

age = int(input("Your age: "))
print(f"Next year you'll be {age + 1}.")

Your age: banana
Traceback (most recent call last):
  File "age.py", line 1, in <module>
    age = int(input("Your age: "))
ValueError: invalid literal for int() with base 10: 'banana'

The program crashes and your user sees a wall of red text. Today's fix:

try:
    age = int(input("Your age: "))
    print(f"Next year you'll be {age + 1}.")
except ValueError:
    print("Please type a number next time.")

The risky line is inside try. If it raises a ValueError, the except block runs instead. The program continues — no crash, no traceback.

The shape

try:
    # risky code
except ExceptionType:
    # what to do if it goes wrong

If anything inside try raises an exception of the type listed in except, Python jumps to the except block. If nothing goes wrong, the except block is skipped entirely.

Reading a traceback

Every traceback follows the same shape. The last line is the most important.

Traceback (most recent call last):
  File "thing.py", line 5, in <module>
    n = int("twelve")
ValueError: invalid literal for int() with base 10: 'twelve'

• Last line — exception type and message. This is what you put in your except clause.
• Middle lines — "call stack" — where in your code it blew up.

The most common exception types

Type                  Caused by

ValueError            int("hi"), float("twelve")
TypeError             "5" + 3, len(7)
ZeroDivisionError     1 / 0
IndexError            list[10] on a 3-item list
KeyError              d["missing"] on a dict
FileNotFoundError     open("does-not-exist.txt")
PermissionError       writing to a read-only file
KeyboardInterrupt     user pressed Ctrl+C
StopIteration         (advanced — iterating past the end)

You don't need to memorise them — they appear in tracebacks all the time and you'll soon recognise the regulars.

The two main shapes

1 · Recover and continue. Catch, tell the user, loop again.

while True:
    try:
        n = int(input("Pick a number: "))
        break
    except ValueError:
        print("Numbers only — try again.")
print(f"You picked {n}.")

2 · Catch and fall back. If the risky thing fails, use a default.

try:
    with open("scores.txt") as f:
        scores = [int(line) for line in f]
except FileNotFoundError:
    scores = []        # treat "no file" as "no scores yet"

print(f"Loaded {len(scores)} scores.")

Don't do this · bare except

Writing except: with no type catches everything — including KeyboardInterrupt (Ctrl+C) and bugs in your own code. Your program ignores them silently and becomes very hard to debug.

# ❌ Don't write code like this
try:
    do_stuff()
except:
    pass          # the silent killer — swallows EVERYTHING

Always name the exception you're actually expecting. The minimum acceptable improvement is except Exception as e: — at least that still lets KeyboardInterrupt through and gives you the error message in e.

Capturing the message · as e

Use except SomeError as e to get the actual exception object, which you can print or log.

try:
    age = int(input("Age: "))
except ValueError as e:
    print(f"Sorry — that didn't work: {e}")

For the input "abc", the print becomes Sorry — that didn't work: invalid literal for int() with base 10: 'abc'.

LBYL vs EAFP

Two philosophies, both legitimate:

# LBYL — Look Before You Leap
text = input("Number: ")
if text.isdigit():
    n = int(text)
else:
    print("Not a number.")

# EAFP — Easier to Ask Forgiveness than Permission
try:
    n = int(input("Number: "))
except ValueError:
    print("Not a number.")

Python folks lean EAFP. The check inside if is often a sloppy duplicate of what the function will do anyway — and easier to get wrong. Try the thing; catch the failure. That's the Pythonic way.

The story

Build a tiny age-gate that asks for the user's age. It must survive any input — including blank strings, letters, negative numbers and silly large values — without crashing.

Save as age_gate.py:

# age_gate.py — bullet-proof age input

while True:
    raw = input("Your age (1-120): ").strip()

    try:
        age = int(raw)
    except ValueError:
        print("  ! Not a number. Try again.")
        continue

    if age < 1 or age > 120:
        print(f"  ! {age} is not a realistic age. Try again.")
        continue

    break

print(f"\nThank you. You are {age} years old.")
if age >= 13:
    print("You're old enough to use this service.")
else:
    print("Sorry, this service is for 13 and up.")

Sample session

Your age (1-120): banana
  ! Not a number. Try again.
Your age (1-120):
  ! Not a number. Try again.
Your age (1-120): -7
  ! -7 is not a realistic age. Try again.
Your age (1-120): 12

Thank you. You are 12 years old.
Sorry, this service is for 13 and up.

Read the diff

Two layers of validation. The try handles "the input wasn't a number at all". The if handles "it was a number but the value is wrong". Both continue back to the top of the loop. break only runs when both layers pass — clean control flow.

Exceptions are Python's "something went wrong" signal. Wrap a risky operation in try: and catch a specific failure with except SomeError:. The last line of a traceback always tells you what type of exception was raised — that's the name you put in your except. Never use bare except: — it swallows even Ctrl+C and your own bugs. Prefer EAFP: try the thing, catch the failure.