Reading a Traceback

By the end of this lesson you can read a traceback and say, without guessing, which line failed, what kind of failure it was, and what to check first.

A traceback looks like a wall of text, so people skim it, see red, and start changing things. Almost all of the information needed to fix the problem is in two lines of it, and reading those two lines is faster than any amount of experimentation.

This also matters when working with an assistant. Pasting the traceback along with the relevant code gets a useful answer; pasting "it doesn't work" gets a guess. Being able to say "it raises a KeyError for agency on the loop line" is often enough to fix it yourself before you finish typing the question.

A traceback is the stack of calls that were in progress when the failure happened, printed oldest first. Read it from the bottom up.

• The last line is the exception type and its message. That is what went wrong.
• The lines just above it are the innermost frame: the file, the line number, and the source of the line that raised.
• Each block above that is the caller of the block below it, back to where the program started.

Your own code is usually the lowest block whose path you recognise. When a failure happens inside a library, the frame you can act on is normally the last one of yours before the library takes over.

Five exception types cover most early failures:

• KeyError — a dictionary key that does not exist. The message names the key.
• IndexError — a list position beyond the end.
• TypeError — an operation between incompatible types, such as adding text to a number.
• ValueError — the right type but an unusable value, such as int("12 apples").
• AttributeError — a method or attribute the object does not have; often means the value is not the type you assumed, and NoneType in the message almost always means something returned None.

Then form one hypothesis, in the shape "I believe X, because the traceback says Y", and test exactly that. Print the suspect value, or check the record the loop was on. Changing several things at once means that when the error goes away you will not know which change did it, and whether the others introduced something new.

def response_window(record):
    return record["response_due"] - record["posted_date"]


def summarise(batch):
    for record in batch:
        print(record["notice_id"], response_window(record))


summarise([{"notice_id": "A-1", "posted_date": "2026-03-04", "response_due": "2026-04-01"}])

The traceback this produces:

Traceback (most recent call last):
  File "report.py", line 10, in <module>
    summarise([{"notice_id": "A-1", ...}])
  File "report.py", line 7, in summarise
    print(record["notice_id"], response_window(record))
  File "report.py", line 2, in response_window
    return record["response_due"] - record["posted_date"]
TypeError: unsupported operand type(s) for -: 'str' and 'str'

Read it bottom-up. The last line says a subtraction was attempted between two strings, which Python does not define. The frame above it points at line 2, inside response_window, and shows the exact expression.

The two frames above that are the path that got there: summarise called it from line 7, and the top-level call is on line 10. That path is context, not the fault. The fault is that both dates are text, and text cannot be subtracted; they need parsing into date values first, which is Module 6's work.

summarise([{"notice_id": "A-1", "posted_date": "2026-03-04", "response_due": "2026-04-01"}])

print(record["notice_id"], response_window(record))

return record["response_due"] - record["posted_date"]

TypeError: unsupported operand type(s) for -: 'str' and 'str'

Does the program print anything before it fails? Predict what appears, and in what order.

Change response_window to return len(record["response_due"]) - len(record["posted_date"]). Predict what the program prints now.

An assistant was given a NoneType error and produced this "fix", saying the problem was a missing default.

def find_record(batch, notice_id):
    for record in batch:
        if record["notice_id"] == notice_id:
            return record


batch = [{"notice_id": "A-1", "estimated_value": 300000}]

record = find_record(batch, "A-9")
value = record.get("estimated_value", 0)
print(value)

AttributeError: 'NoneType' object has no attribute 'get'

Run the program below first. Read the traceback, identify the offending line, and repair it so every record prints, with a missing agency shown as unknown agency.

Loading this exercise…

Optional: reintroduce the crash, then add print(record) as the first line of the loop body and run it again. Confirm that the last record printed before the traceback is the one that caused it. Then remove the debugging line. Learning to narrow a data-dependent failure to a specific record, and then to clean up after yourself, is the whole loop of practical debugging.

Sign in to track your progress on this exercise.

Match each message to its most likely cause:

1. KeyError: 'response_due'
2. TypeError: '>' not supported between instances of 'str' and 'int'
3. AttributeError: 'NoneType' object has no attribute 'append'
4. ValueError: invalid literal for int() with base 10: '96,500'
5. IndexError: list index out of range

Sign in to track your progress on this exercise.

Read a traceback bottom-up, the last line names the failure, the frame above it names your line, five exception types cover most early bugs, NoneType means something returned nothing, and a disappearing error is not proof of a fixed cause. Next: handling the failures worth handling, and refusing to hide the rest.