Errors and exceptions

Make a day15 folder for today’s files, open it in your editor, and run each script from its terminal, as on earlier days.

Since Day 1 your programs have stopped with error messages: a NameError for a misspelled name, a ValueError when int() got a word, a ZeroDivisionError when a count was 0. Each time, the fix was to change the code. But some errors are not the programmer’s fault. A user types twelve where you asked for a number. A save file gets deleted, or half written when the laptop’s battery dies. A program cannot prevent those, so it must be ready for them. Days 3 and 5 promised that today you would learn how. By the end of today your programs will answer bad input with a clear message instead of a crash, and your to-do manager will survive a missing or broken save file.

Before you can handle an error, you need to read what Python tells you about it. On Day 1 every error came from one line in the main part of a file. Since Day 9 your programs call functions, and functions call other functions, so an error can happen several calls deep. The report then gets longer.

When a running program hits a problem it cannot get past, Python raises an exception: it stops what it was doing and creates an exception, a value that describes what went wrong. If nothing in the program deals with the exception, the program stops and prints a traceback, the report you met on Day 1. Its name is literal: it traces back through every function call that was in progress when the error happened.

def average(prices):
    return sum(prices) / len(prices)


def report(day, prices):
    print(f"{day}: {average(prices):.2f}")


report("Monday", [4.5, 3.0, 6.0])
report("Tuesday", [])
report("Wednesday", [2.0, 5.0])

Monday: 4.50
Traceback (most recent call last):
  File ".../day15/receipt_average.py", line 10, in <module>
    report("Tuesday", [])
    ~~~~~~^^^^^^^^^^^^^^^
  File ".../day15/receipt_average.py", line 6, in report
    print(f"{day}: {average(prices):.2f}")
                    ~~~~~~~^^^^^^^^
  File ".../day15/receipt_average.py", line 2, in average
    return sum(prices) / len(prices)
           ~~~~~~~~~~~~^~~~~~~~~~~~~
ZeroDivisionError: division by zero

So the bottom frame says where the program crashed, and the frames above it say how it got there. You need both, because the line that crashed is not always the line with the bug, as the Watch Out below shows.

The same reading works when the error happens inside one of Python’s built-in functions. Here the text "four" reaches int() two calls deep:

def parse_guests(text):
    return int(text)


def split_bill(total, guests_text):
    guests = parse_guests(guests_text)
    return total / guests


print(split_bill(60, "4"))
print(split_bill(60, "four"))

15.0
Traceback (most recent call last):
  File ".../day15/split_bill.py", line 11, in <module>
    print(split_bill(60, "four"))
          ~~~~~~~~~~^^^^^^^^^^^^
  File ".../day15/split_bill.py", line 6, in split_bill
    guests = parse_guests(guests_text)
  File ".../day15/split_bill.py", line 2, in parse_guests
    return int(text)
ValueError: invalid literal for int() with base 10: 'four'

The bottom line is the Day 2 ValueError. The bottom frame is parse_guests, line 2, where int(text) ran. One frame up, split_bill passed it guests_text, and one more frame up, line 11 is where "four" came from. Python does not always draw the marks; when they would just underline the whole expression on the line, as in return int(text), it leaves them out.

def lookup(prices, item):
    return prices[item]


def basket_total(prices, items):
    total = 0
    for item in items:
        total += lookup(prices, item)
    return total


prices = {"apple": 0.5, "bread": 2.25}
print(basket_total(prices, ["apple", "bread"]))
print(basket_total(prices, ["apple", "milk"]))

2.75
Traceback (most recent call last):
  ...
KeyError: 'milk'

The last line of a traceback starts with the exception’s type, a name such as ValueError. Every exception has a type, and the type tells you what kind of problem happened before you read the rest of the message. A handful of types cover most beginner errors. You have met each of them on an earlier day:

>>> int("ten")
Traceback (most recent call last):
  ...
ValueError: invalid literal for int() with base 10: 'ten'

>>> "Score: " + 90
Traceback (most recent call last):
  ...
TypeError: can only concatenate str (not "int") to str

>>> prices = {"apple": 0.5}
>>> prices["pear"]
Traceback (most recent call last):
  ...
KeyError: 'pear'

>>> scores = [90, 85]
>>> scores[2]
Traceback (most recent call last):
  ...
IndexError: list index out of range

>>> open("missing_notes.txt", encoding="utf-8")
Traceback (most recent call last):
  ...
FileNotFoundError: [Errno 2] No such file or directory: 'missing_notes.txt'

>>> 12 / 0
Traceback (most recent call last):
  ...
ZeroDivisionError: division by zero

In the REPL the traceback is shorter, because there is no file: only the last line matters. Each line asks for something impossible in a different way:

The difference between ValueError and TypeError trips people up, so compare them directly. int("ten") is a ValueError: int() happily accepts strings, so the type is fine, but the string "ten" has no whole-number meaning. "Score: " + 90 is a TypeError: + cannot join a string and an int no matter what the values are, so the problem is the type itself.

When you see FileNotFoundError, check the spelling of the path it names and which folder the program runs from (Day 14).

Here is a ticket program in the style of Day 5. It works well until a user types a word:

age = int(input("Age: "))
print(f"Your ticket costs {5 if age < 12 else 9} dollars.")
print("Enjoy the film!")

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

Checking the text with an if before calling int() is harder than it looks: there are many ways to write a number (12, -3, +7) and even more ways not to (15.9 comes back to this). What you want is to try the conversion, and if it fails, do something sensible instead of crashing.

That is the job of the try statement. Python runs the code in its try block. If an exception of the type you named happens there, Python does not stop the program; it jumps to your except block instead. Running an except block for an exception is called catching or handling it.

try:
    statements that might raise an exception
except ExceptionType:
    statements to run if that exception happens

• try: starts the try block: the indented lines Python will attempt.
• except ValueError: is an except clause. It names the exception type to catch, and its indented block is the handler.
• After either block finishes, the program carries on with the first line after the whole statement.

try:
    age = int(input("Age: "))
    print(f"Your ticket costs {5 if age < 12 else 9} dollars.")
except ValueError:
    print("Please type your age as a number, such as 12.")
print("Enjoy the film!")

Age: twelve
Please type your age as a number, such as 12.
Enjoy the film!

The key detail is step 3. An exception does not finish the try block; it leaves it at once. To see both paths in one run, this loop tries three strings:

for text in ["12", "twelve", "7"]:
    print(f"Trying {text}")
    try:
        age = int(text)
        print(f"  Next year: {age + 1}")
    except ValueError:
        print("  Not a whole number")
print("All done")

Trying 12
  Next year: 13
Trying twelve
  Not a whole number
Trying 7
  Next year: 8
All done

For "twelve", line 4 raises, so line 5 never runs for it. The handler prints its message, and the loop goes on to "7" as usual. A handled exception affects only the try statement it happened in.

text = "twelve"
try:
    age = int(text)
except ValueError:
    print("Not a number.")
print(f"Next year you will be {age + 1}.")

Not a number.
Traceback (most recent call last):
  File ".../day15/skipped_assignment.py", line 6, in <module>
    print(f"Next year you will be {age + 1}.")
                                   ^^^
NameError: name 'age' is not defined

total = 0
for text in ["5", "five", "2.5", "10"]:
    try:
        total += int(text)
        print(f"added {text}")
    except ValueError:
        print(f"skipped {text}")
print(f"total {total}")

added 5
skipped five
skipped 2.5
added 10
total 15

One try block can fail in more than one way, and each way usually needs a different message. This program shares pizza slices: the text might not be a number, or the number of people might be 0.

def share(slices_text, people_text):
    try:
        slices = int(slices_text)
        people = int(people_text)
        print(f"{slices // people} slices each")
    except ValueError:
        print("Type whole numbers, such as 12 and 4.")
    except ZeroDivisionError:
        print("Nobody to share with: people must be at least 1.")


for slices_text, people_text in [("12", "4"), ("12", "four"), ("12", "0")]:
    share(slices_text, people_text)

3 slices each
Type whole numbers, such as 12 and 4.
Nobody to share with: people must be at least 1.

When two exceptions deserve the same handling, list them in a tuple, and add as with a name to get hold of the exception itself:

def share(slices_text, people_text):
    try:
        slices = int(slices_text)
        people = int(people_text)
        print(f"{slices // people} slices each")
    except (ValueError, ZeroDivisionError) as error:
        print(f"Could not share: {error}")


for slices_text, people_text in [("12", "4"), ("12", "four"), ("12", "0")]:
    share(slices_text, people_text)

3 slices each
Could not share: invalid literal for int() with base 10: 'four'
Could not share: division by zero

except (ValueError, ZeroDivisionError) as error: catches either type and stores the exception in error. Putting error in an f-string (or calling str(error)) gives its message, the text after the colon on a traceback’s last line. For a KeyError, the message is the missing key in quotes, such as 'pear'.

What about an exception you did not list? It is not caught. It carries on exactly as if there were no try statement, and stops the program:

def share(slices_text, people_text):
    try:
        slices = int(slices_text)
        people = int(people_text)
        print(f"{slices // people} slices each")
    except ValueError:
        print("Type whole numbers, such as 12 and 4.")


share("12", "4")
share("12", "0")
print("Done sharing")

3 slices each
Traceback (most recent call last):
  File ".../day15/share_pizza_uncaught.py", line 11, in <module>
    share("12", "0")
    ~~~~~^^^^^^^^^^^
  File ".../day15/share_pizza_uncaught.py", line 5, in share
    print(f"{slices // people} slices each")
             ~~~~~~~^^~~~~~~~
ZeroDivisionError: division by zero

This is a feature, not a gap. You catch the problems you expect and know how to answer. A problem you did not expect is probably a bug, and a bug should stop the program loudly, with a traceback that points straight at it.

def total_cost(price_text, quantity_text):
    try:
        price = float(price_text)
        quantity = int(quantity_text)
        return price * quantiy
    except:
        print("Please type numbers.")


print(total_cost("2.50", "4"))

Please type numbers.
None

def total_cost(price_text, quantity_text):
    try:
        price = float(price_text)
        quantity = int(quantity_text)
        return price * quantiy
    except ValueError:
        print("Please type numbers.")


print(total_cost("2.50", "4"))

Traceback (most recent call last):
  File ".../day15/bare_except_fixed.py", line 10, in <module>
    print(total_cost("2.50", "4"))
          ~~~~~~~~~~^^^^^^^^^^^^^
  File ".../day15/bare_except_fixed.py", line 5, in total_cost
    return price * quantiy
                   ^^^^^^^
NameError: name 'quantiy' is not defined. Did you mean: 'quantity'?

stock = {"pens": 12, "pads": 0}

for item in ["pens", "pads", "rulers"]:
    try:
        per_box = 24 // stock[item]
        print(f"{item}: {per_box}")
    except ZeroDivisionError:
        print(f"{item}: out of stock")
    except KeyError:
        print(f"{item}: we do not sell these")
print("Report done")

pens: 2
pads: out of stock
rulers: we do not sell these
Report done

15.3 left a question open: where should the code go that uses a successful result? You could put it all in the try block, but then every line there is “protected”, and an unexpected ValueError from some later line would be caught by a handler written for the conversion. Good try blocks are small: only the line that can fail in the way you expect. A try statement has two more optional clauses for the rest.

• An else clause runs only if the try block finished without an exception. Put the code that uses the result there.
• A finally clause runs always, whether the try block succeeded, failed and was handled, or failed and was not handled. Put cleanup there: anything that must happen no matter what.

The full shape, in the only order Python accepts:

try:
    risky line
except SomeError:
    runs if SomeError happened
else:
    runs if nothing went wrong
finally:
    runs every time

for text in ["88", "eighty"]:
    print(f"Reading {text}")
    try:
        score = int(text)
    except ValueError:
        print("  except: not a number")
    else:
        print(f"  else: doubled is {score * 2}")
    finally:
        print("  finally: checked")

Reading 88
  else: doubled is 176
  finally: checked
Reading eighty
  except: not a number
  finally: checked

finally runs even when the exception is not caught. Here there is no except clause at all, which is allowed:

try:
    print("Saving...")
    share = 10 / 0
finally:
    print("Cleanup runs anyway")
print("Never printed")

Saving...
Cleanup runs anyway
Traceback (most recent call last):
  File ".../day15/finally_uncaught.py", line 3, in <module>
    share = 10 / 0
            ~~~^~~
ZeroDivisionError: division by zero

The division fails, Python runs the finally block on its way out, and then the program stops with the traceback. Never printed never prints. finally also runs when the try block is left by return or break. Here the function has already worked out its return value, but finally prints before the value is handed back:

def first_letter(word):
    try:
        return word[0]
    finally:
        print(f"checked {word}")


print(first_letter("kiwi"))

checked kiwi
k

On Day 14, with open(...) closed the file for you even if something went wrong inside the with block. Now you can see what that means: with does the same job as a finally that closes the file, built in.

try:
    count = int("7")
finally:
    print("Finished")
except ValueError:
    print("Not a number")

  File ".../day15/wrong_order.py", line 5
    except ValueError:
    ^^^^^^
SyntaxError: invalid syntax

line = ""
for text in ["4", "x", "0"]:
    try:
        number = int(text)
        result = 12 // number
    except ValueError:
        line += "V"
    except ZeroDivisionError:
        line += "Z"
    else:
        line += str(result)
    finally:
        line += "|"
print(line)

3|V|Z|

In 15.1 the traceback listed every function call that was in progress. Those same calls decide where an exception can be caught. When a function raises an exception and does not handle it, the function stops at once (no return happens), and the exception arrives at the line that called the function, as if that line had raised it. If that line is in a try block with a matching except clause, the exception is caught there. If not, it carries on up to the next caller, and so on. Passing up through the calls like this is called propagating. Only if it reaches the main part of the file with nothing to catch it does the program stop with a traceback.

def parse_quantity(text):
    print(f"  parsing {text}")
    quantity = int(text)
    print("  parsed")
    return quantity


def place_order(text):
    quantity = parse_quantity(text)
    print(f"  ordered {quantity}")


for text in ["3", "lots"]:
    print(f"Order: {text}")
    try:
        place_order(text)
    except ValueError:
        print("  cancelled: bad quantity")
print("Shop still open")

Order: 3
  parsing 3
  parsed
  ordered 3
Order: lots
  parsing lots
  cancelled: bad quantity
Shop still open

This means you can catch an error far from where it happens, and usually you should. parse_quantity knows how to convert text, but it does not know what the program should do with a bad quantity: ask again? Skip the order? Show a message in a window? The code near the user knows. A good rule: handle an exception at the place that can do something useful about it. Low-level functions let it propagate, and the code that talks to the user catches it.

def inner(n):
    print("inner start")
    result = 10 // n
    print("inner end")
    return result


def outer(n):
    try:
        print("outer start")
        value = inner(n)
        print("outer got", value)
    finally:
        print("outer finally")


try:
    outer(0)
except ZeroDivisionError:
    print("caught at the top")

outer start
inner start
outer finally
caught at the top

So far Python has raised every exception. But your own functions also meet values they cannot use. A function that reads a rating from 1 to 5 gets "9". int("9") is happy, so Python raises nothing, but 9 is still wrong. What should the function do?

It could print a message, but then it decides how the problem is shown, which is the caller’s job (15.6). It could return None, but a caller that forgets to check will carry on with None and crash somewhere later, far from the cause. Python’s answer is that the function raises an exception itself, exactly like int() does. The raise statement creates an exception and raises it:

raise ValueError("a message that explains the problem")

• raise is a keyword.
• ValueError(...) creates a new exception of that type. The text in the parentheses becomes its message.
• From that moment, everything works as in 15.6: the function stops, and the exception propagates to the caller.

def parse_rating(text):
    rating = int(text)
    if not 1 <= rating <= 5:
        raise ValueError(f"rating must be 1 to 5, not {rating}")
    return rating


for text in ["4", "9", "great"]:
    try:
        rating = parse_rating(text)
    except ValueError as error:
        print(f"Skipped {text}: {error}")
    else:
        print(f"Saved rating {rating}")

Saved rating 4
Skipped 9: rating must be 1 to 5, not 9
Skipped great: invalid literal for int() with base 10: 'great'

If nobody catches a raised exception, it ends the program with a traceback like any other, and the message is the one you wrote:

def parse_rating(text):
    rating = int(text)
    if not 1 <= rating <= 5:
        raise ValueError(f"rating must be 1 to 5, not {rating}")
    return rating


print(parse_rating("4"))
print(parse_rating("9"))
print("Not reached")

4
Traceback (most recent call last):
  File ".../day15/rating_uncaught.py", line 9, in <module>
    print(parse_rating("9"))
          ~~~~~~~~~~~~^^^^^
  File ".../day15/rating_uncaught.py", line 4, in parse_rating
    raise ValueError(f"rating must be 1 to 5, not {rating}")
ValueError: rating must be 1 to 5, not 9

That is why a good message says what was expected and what arrived. Whoever reads this traceback knows what went wrong without opening the code.

def parse_rating(text):
    rating = int(text)
    if not 1 <= rating <= 5:
        return ValueError(f"rating must be 1 to 5, not {rating}")
    return rating


for text in ["4", "9"]:
    try:
        rating = parse_rating(text)
    except ValueError as error:
        print(f"Skipped {text}: {error}")
    else:
        print(f"Saved rating {rating}")

Saved rating 4
Saved rating rating must be 1 to 5, not 9

In the to-do manager, a user can type two (not a number) or 7 (a number, but no such task). Both could be ValueError, but then the handler cannot tell them apart and cannot give a precise message. Worse, a ValueError from some other line, maybe a real bug, would be caught by the same handler.

You can make your own exception type with a name that says exactly what went wrong. A custom exception takes two lines. Copy this pattern and change only the name:

class TaskNumberError(Exception):
    pass

Tomorrow, Day 16, explains class properly. For today, here is what each piece does:

• class TaskNumberError creates a new type named TaskNumberError. By convention, the names of exception types end in Error and are written in CapWords (each word starts with a capital letter, no underscores), like the built-in ones.
• (Exception) makes the new type a kind of exception, so it can be raised and caught. Leave it out and Python refuses to raise it.
• pass is a statement that does nothing. A block cannot be empty, and this one has nothing to say, so pass fills it.

Put the two lines near the top of the file, below the imports, so the type exists before any code raises or catches it. After that, TaskNumberError works like ValueError: you raise it with a message and catch it by name.

class TaskNumberError(Exception):
    pass


def check_task_number(tasks, number):
    if not 1 <= number <= len(tasks):
        raise TaskNumberError(f"there is no task {number}; choose 1 to {len(tasks)}")


tasks = [{"title": "Buy milk", "done": False}, {"title": "Walk dog", "done": True}]
for typed in ["2", "7", "two"]:
    try:
        number = int(typed)
        check_task_number(tasks, number)
    except ValueError:
        print(f"{typed}: please type a number")
    except TaskNumberError as error:
        print(f"{typed}: {error}")
    else:
        print(f"{typed}: {tasks[number - 1]['title']}")

2: Walk dog
7: there is no task 7; choose 1 to 2
two: please type a number

Uncaught, your exception produces a normal traceback, ending with your type’s name and message:

class TaskNumberError(Exception):
    pass


def check_task_number(tasks, number):
    if not 1 <= number <= len(tasks):
        raise TaskNumberError(f"there is no task {number}; choose 1 to {len(tasks)}")


tasks = [{"title": "Buy milk", "done": False}]
check_task_number(tasks, 1)
print("Task 1 is fine")
check_task_number(tasks, 3)

Task 1 is fine
Traceback (most recent call last):
  File ".../day15/task_number_uncaught.py", line 13, in <module>
    check_task_number(tasks, 3)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../day15/task_number_uncaught.py", line 7, in check_task_number
    raise TaskNumberError(f"there is no task {number}; choose 1 to {len(tasks)}")
TaskNumberError: there is no task 3; choose 1 to 1

class TaskNumberError:
    pass


raise TaskNumberError("there is no task 3")

Traceback (most recent call last):
  File ".../day15/no_exception_base.py", line 5, in <module>
    raise TaskNumberError("there is no task 3")
          ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
TypeError: TaskNumberError() takes no arguments

class SeatError(Exception):
    pass


def check_seat(row, seat):
    if seat > 10:
        raise SeatError(f"row {row} has only 10 seats")
    return f"{row}{seat}"


def book(row, seat_text):
    seat = int(seat_text)
    label = check_seat(row, seat)
    print(f"booked {label}")


for row, seat_text in [("A", "4"), ("B", "12"), ("C", "two")]:
    try:
        book(row, seat_text)
    except SeatError as error:
        print(f"sorry, {error}")
    except ValueError:
        print("seat must be a number")
print("done")

booked A4
sorry, row B has only 10 seats
seat must be a number
done

You now have two ways to deal with something that might fail. You can check first, and only act if the check passes. Or you can just act, and handle the exception if it fails. Both appear in Python code, and they have names:

• LBYL, “look before you leap”: test the conditions with if, then act.
• EAFP, “easier to ask forgiveness than permission”: act inside a try, and handle the failure in except.

stock = {"pens": 12, "pads": 5}

# Look before you leap: check first, then act.
item = "rulers"
if item in stock:
    print(f"{item}: {stock[item]}")
else:
    print(f"{item}: not stocked")

# Easier to ask forgiveness than permission: act, and handle the failure.
try:
    print(f"{item}: {stock[item]}")
except KeyError:
    print(f"{item}: not stocked")

rulers: not stocked
rulers: not stocked

For a dictionary, both styles are fine. But in other places, checking first is harder than it looks. Think about checking text before int(). These all work:

>>> int("-7")
-7
>>> int(" 42 ")
42
>>> int("+3")
3
>>> int("4.0")
Traceback (most recent call last):
  ...
ValueError: invalid literal for int() with base 10: '4.0'

A minus sign, spaces around the number, and a plus sign are all accepted, but "4.0" is not. An if that tried to copy int()’s rules would be long and still miss a case. The Day 12 to-do manager stripped the spaces off and then checked all(ch in "0123456789" for ch in text): two steps to copy part of int()’s rules, and it still refuses +3, which int() accepts. EAFP asks the expert: let int() decide, and catch the ValueError.

Files make the strongest case for EAFP. On Day 14 the to-do manager checked SAVE_FILE.exists() before loading. But a file can be deleted between the check and the open, and a file that exists can still be unreadable, or not valid JSON. The check answers one question once; it cannot promise that the next line will work. Trying to open the file and catching FileNotFoundError covers the real moment of opening.

Python programmers lean toward EAFP, because it puts the normal path first and lets the code that does the work decide what counts as failure. Neither is wrong; choose the one whose check is honest and complete.

A teacher keeps scores in a text file, one name,score per line. Some lines have mistakes. The program reports the average of the good lines and explains each bad one, and it copes when the file is missing.

class_scores.txt:

Ana,88
Ben,ninety
Cy
Dee,105
Eli,72

from pathlib import Path


class ScoreRangeError(Exception):
    pass


def read_lines(path):
    with open(path, encoding="utf-8") as file:
        return [line.strip() for line in file]


def parse_line(line):
    name, score_text = line.split(",")
    score = int(score_text)
    if not 0 <= score <= 100:
        raise ScoreRangeError(f"{score} is outside 0 to 100")
    return name, score


def read_scores(path):
    try:
        lines = read_lines(path)
    except FileNotFoundError:
        print(f"No file named {path}: nothing to report.")
        return []
    scores = []
    for number, line in enumerate(lines, 1):
        try:
            name, score = parse_line(line)
        except (ValueError, ScoreRangeError) as error:
            print(f"Line {number} skipped ({line}): {error}")
        else:
            scores.append(score)
    return scores


for path in [Path("class_scores.txt"), Path("missing_scores.txt")]:
    scores = read_scores(path)
    if scores:
        print(f"{len(scores)} scores, average {sum(scores) / len(scores):.1f}")

Line 2 skipped (Ben,ninety): invalid literal for int() with base 10: 'ninety'
Line 3 skipped (Cy): not enough values to unpack (expected 2, got 1)
Line 4 skipped (Dee,105): 105 is outside 0 to 100
2 scores, average 80.0
No file named missing_scores.txt: nothing to report.

• read_lines does not handle anything. When missing_scores.txt does not exist, its open raises FileNotFoundError, which propagates (15.6) to read_scores, where the except clause prints a message and returns an empty list. The final if scores: then skips the average, so there is no ZeroDivisionError either.
• The try block around read_lines holds one line, and the try block in the loop holds one line. Each catches only the exceptions it expects, named exactly (15.4), and none is bare.
• The unpacking line shows that you do not need to predict every way a line can be broken: int() and unpacking raise ValueError for you, the program checks only what Python cannot (the range), and one handler covers them all (EAFP, 15.9).
• The average is (88 + 72) / 2 = 80.0.

• An uncaught exception stops the program with a traceback. Read it from the bottom up: the last line gives the type and message, the bottom frame shows where it happened, and the frames above show which calls led there; the cause may be in any of them.
• The common types each name a kind of problem: ValueError, TypeError, KeyError, IndexError, FileNotFoundError, and ZeroDivisionError.
• A try statement runs its block, jumps to the first matching except handler if a listed exception happens, runs else if nothing did, and runs finally every time. Catch only the types you expect, never with a bare except.
• An unhandled exception propagates from a function to its caller, so you can catch it where the program can respond. Your functions can raise exceptions too, including custom types made with class Name(Exception): pass.
• EAFP (try, then handle) is often clearer and safer than LBYL (check first), especially for converting text and opening files.

Do these in your day15 folder. Type each program yourself, run it, and only then open the answer.

def read_int(prompt):
    """Ask until the user types a whole number, then return it as an int."""
    while True:
        text = input(prompt)
        try:
            return int(text)
        except ValueError:
            print("Please type a whole number, such as 12.")


age = read_int("Age: ")
tickets = read_int("Tickets: ")
print(f"{tickets} tickets for age {age}")

Age: twelve
Please type a whole number, such as 12.
Age: 12.5
Please type a whole number, such as 12.
Age: 12
Tickets:
Please type a whole number, such as 12.
Tickets: 3
3 tickets for age 12

[
  {
    "title": "Return library books",
    "done": tr

import json

with open("corrupted.json", encoding="utf-8") as file:
    tasks = json.load(file)
print(tasks)

Traceback (most recent call last):
  File ".../day15/todo_app/crash_load.py", line 4, in <module>
    tasks = json.load(file)
  File ".../json/__init__.py", line 298, in load
  ...
  File ".../json/decoder.py", line 363, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 4 column 13 (char 55)

"""Task functions for the to-do manager. main.py imports them."""

import json


def show_menu():
    """Print the menu of choices."""
    print()
    print("1) Add  2) List  3) Complete  4) Delete  5) Quit")


def add_task(tasks, title):
    """Add a new, unfinished task to the end of tasks."""
    tasks.append({"title": title, "done": False})


def list_tasks(tasks):
    """Print every task with its number and a check box."""
    if not tasks:
        print("No tasks yet.")
        return
    for number, task in enumerate(tasks, 1):
        mark = "x" if task["done"] else " "
        title = task["title"]
        print(f"{number}. [{mark}] {title}")


def complete_task(tasks, number):
    """Mark task number (counting from 1) as done.

    Return the task, or None if no task has that number.
    """
    if not 1 <= number <= len(tasks):
        return None
    task = tasks[number - 1]
    task["done"] = True
    return task


def delete_task(tasks, number):
    """Remove task number (counting from 1) from tasks.

    Return the removed task, or None if no task has that number.
    """
    if not 1 <= number <= len(tasks):
        return None
    return tasks.pop(number - 1)


def save_tasks(tasks, path):
    """Write tasks to the JSON file at path, replacing what was there."""
    with path.open("w", encoding="utf-8") as file:
        json.dump(tasks, file, indent=2)


def load_tasks(path):
    """Return the tasks saved at path, or [] if there are none to load.

    A missing file means this is the first run. A file that is not valid
    JSON gets a warning, and the program starts with no tasks.
    """
    try:
        with path.open(encoding="utf-8") as file:
            return json.load(file)
    except FileNotFoundError:
        return []
    except json.JSONDecodeError:
        print(f"Warning: {path.name} is not valid JSON, so no tasks loaded.")
        return []


if __name__ == "__main__":
    test_tasks = []
    add_task(test_tasks, "Test the module")
    print(complete_task(test_tasks, 1))
    print(complete_task(test_tasks, 2))
    list_tasks(test_tasks)

"""The to-do manager's menu loop. Run this file to start the program."""

from pathlib import Path

from tasks import (
    add_task,
    complete_task,
    delete_task,
    list_tasks,
    load_tasks,
    save_tasks,
    show_menu,
)

SAVE_FILE = Path(__file__).parent / "tasks.json"


def main():
    """Run the menu loop until the user chooses Quit."""
    tasks = load_tasks(SAVE_FILE)
    print("To-do list manager")
    print(f"Loaded {len(tasks)} tasks from {SAVE_FILE.name}")
    while True:
        show_menu()
        choice = input("Choose 1-5: ").strip()
        if choice == "1":
            title = input("Task title: ").strip()
            if title:
                add_task(tasks, title)
                save_tasks(tasks, SAVE_FILE)
                print(f"Added: {title}")
            else:
                print("A task needs a title.")
        elif choice == "2":
            list_tasks(tasks)
        elif choice in ("3", "4"):
            try:
                number = int(input("Task number: "))
            except ValueError:
                print("Please type a task number, such as 1.")
                continue
            if choice == "3":
                task = complete_task(tasks, number)
                action = "Completed"
            else:
                task = delete_task(tasks, number)
                action = "Deleted"
            if task is None:
                print(f"There is no task {number}.")
            else:
                save_tasks(tasks, SAVE_FILE)
                title = task["title"]
                print(f"{action}: {title}")
        elif choice == "5":
            print("Goodbye!")
            break
        else:
            print("Please choose a number from 1 to 5.")


if __name__ == "__main__":
    main()

To-do list manager
Loaded 2 tasks from tasks.json

1) Add  2) List  3) Complete  4) Delete  5) Quit
Choose 1-5: 2
1. [x] Return library books
2. [ ] Practice piano

1) Add  2) List  3) Complete  4) Delete  5) Quit
Choose 1-5: 3
Task number: two
Please type a task number, such as 1.

1) Add  2) List  3) Complete  4) Delete  5) Quit
Choose 1-5: 3
Task number: 2
Completed: Practice piano

1) Add  2) List  3) Complete  4) Delete  5) Quit
Choose 1-5: 4
Task number: 9
There is no task 9.

1) Add  2) List  3) Complete  4) Delete  5) Quit
Choose 1-5: 5
Goodbye!

from pathlib import Path

from tasks import list_tasks, load_tasks

for name in ["no_such_file.json", "corrupted.json", "tasks.json"]:
    print(f"Loading {name}:")
    list_tasks(load_tasks(Path(name)))

Loading no_such_file.json:
No tasks yet.
Loading corrupted.json:
Warning: corrupted.json is not valid JSON, so no tasks loaded.
No tasks yet.
Loading tasks.json:
1. [x] Return library books
2. [ ] Practice piano

def parse_price(text):
    """Turn text like "2.50" into a float, or raise ValueError if it is not a usable price."""
    price = float(text)
    if price <= 0:
        raise ValueError(f"a price must be more than 0, not {text}")
    return price


def total_prices(texts):
    total = 0
    for text in texts:
        try:
            price = parse_price(text)
        except ValueError as error:
            print(f"Skipped: {error}")
        else:
            total += price
    return total


print(f"Total: {total_prices(['2.50', 'free', '-1', '4.25']):.2f}")

Skipped: could not convert string to float: 'free'
Skipped: a price must be more than 0, not -1
Total: 6.75

def safe_divide(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        return None
    finally:
        print(f"checked {a} / {b}")


print(safe_divide(6, 3))
print(safe_divide(1, 0))

checked 6 / 3
2.0
checked 1 / 0
None

prices = {"apple": 0.5, "bread": 2.25}

for item in ["bread", "milk"]:
    try:
        print(f"{item}: {prices[item]:.2f}")
    except ValueError:
        print(f"{item}: no price")

KeyError: 'milk'

prices = {"apple": 0.5, "bread": 2.25}

for item in ["bread", "milk"]:
    try:
        print(f"{item}: {prices[item]:.2f}")
    except KeyError:
        print(f"{item}: no price")

bread: 2.25
milk: no price

def check_quantity(text):
    quantity = int(text)
    if quantity < 1:
        raise ValueError("must order at least 1")
    return quantity


def order(text):
    try:
        quantity = check_quantity(text)
    except ValueError as error:
        print(f"{text}: {error}")
    else:
        print(f"{text}: ordered {quantity}")
    finally:
        print("--")


for text in ["2", "0", "x"]:
    order(text)

2: ordered 2
--
0: must order at least 1
--
x: invalid literal for int() with base 10: 'x'
--

scores = {"Ana": [90, 85], "Ben": [70]}

for name, index in [("Ana", 1), ("Ben", 1), ("Cy", 0)]:
    try:
        print(scores[name][index])
    except (KeyError, IndexError) as error:
        print(f"problem: {error}")

85
problem: list index out of range
problem: 'Cy'

The official Python Tutorial covers today’s topics, with a few more advanced features such as exception chaining and exception groups, in Errors and Exceptions. Its section on user-defined exceptions uses classes, which you meet tomorrow on Day 16.

Check each statement. If the answer is “not yet,” reread the linked subsection.

• I can read a traceback from the bottom up and find where and why a program stopped. Reread
• I can say what each common exception type means. Reread
• I can catch an exception with try and except and say which lines are skipped. Reread
• I can catch specific exception types, read the message with as, and explain why a bare except is a mistake. Reread
• I can use else and finally and predict when each runs. Reread
• I can follow an exception up through function calls to the handler that catches it. Reread
• I can raise a ValueError with a clear message from my own function. Reread
• I can define, raise, and catch a custom exception. Reread
• I can choose between checking first and trying first, and explain the choice. Reread