The word "Traceback" at the top is easy to ignore — do not. It announces that what follows is a record of where Python was when the error happened. The phrase "most recent call last" tells you the order: the first entry in the list is the outermost call (usually your main program), and the last entry is the innermost call (the exact line that crashed).

For a simple program with no functions, there is only one entry in the traceback and the structure is straightforward. When functions are involved, there can be several entries. The rule is always the same: read the last entry first, because that is the line that actually crashed.

The distinction between syntax and runtime errors matters because they require different responses.

A syntax error means the program could not even start. Python reads through your file before running anything, checking that the code is valid Python syntax. If it finds a problem, it stops immediately and reports the location. Nothing in your program has run yet. The fix is always structural: a missing or extra character, a misspelled keyword, an unclosed bracket.

A runtime error means the program started and ran successfully up to a point, then encountered a situation it could not handle. This is more nuanced: some of your code ran correctly before the crash. The line reported in the error is where execution stopped — but the cause might be earlier, where a variable was given a bad value or a list was built incorrectly.

Here is each error type with a concrete example — the code that causes it, the message Python produces, and the diagnosis.

SyntaxError

if x > 5
    print("big")

Diagnosis: the colon is missing at the end of the if statement. Python even tells you what it expected.

NameError

print(mesage)

Diagnosis: mesage is a typo — the variable is probably called message. The name has never been assigned.

TypeError

age = input("Enter age: ")
next_year = age + 1

Diagnosis: input() always returns a string. Adding the integer 1 to a string is not valid. Fix: age = int(input("Enter age: ")).

IndexError

items = ["a", "b", "c"]
print(items[3])

Diagnosis: the list has three items at indexes 0, 1, and 2. Index 3 does not exist.

KeyError

student = {"name": "Alex", "grade": 9}
print(student["age"])

Diagnosis: the key "age" was never added to the dictionary. The message tells you exactly which key was missing.

ZeroDivisionError

total = 100
count = 0
average = total / count

Diagnosis: count is 0. Division by zero is undefined. Fix: check that count is not zero before dividing.

AttributeError

def get_name():
    print("Alex")

result = get_name()
print(result.upper())

Diagnosis: get_name() prints instead of returning, so result is None. None does not have an upper() method. The message 'NoneType' object has no attribute is almost always a sign that a function returned None when it should have returned a value.

Here is a program with three functions:

def calculate_average(scores):
    return sum(scores) / len(scores)

def process(data):
    result = calculate_average(data)
    return result

def run():
    numbers = []
    print(process(numbers))

run()

Running this produces:

Reading from the bottom:

1. The error: ZeroDivisionError: division by zero. Division by zero happened.
2. The crash site: line 2, inside calculate_average, on the line return sum(scores) / len(scores). The list must be empty, making len(scores) equal to zero.
3. How we got there: reading upward — calculate_average was called from line 5 inside process, which was called from line 9 inside run, which was called from line 11 in the main program.

The diagnosis: numbers was created as an empty list on line 8 and passed into process and then into calculate_average. Dividing by len([]) — which is 0 — caused the crash. The fix is to check that the list is not empty before calculating the average.

Step 4 — writing a diagnosis before touching code — is the step most beginners skip. It feels slower. It is actually faster, because it prevents the most common debugging trap: making random changes until something stops crashing.

Random changes are dangerous for two reasons. First, they can mask the original error without fixing it — the program stops crashing for a different reason, and the underlying bug is still there. Second, they introduce new code that you did not fully understand, which can cause new bugs.

A written diagnosis forces you to commit to a theory. If your fix works, your theory was right and you have learned something. If it does not, you know your theory was wrong and you can form a different one. Either way you are learning.

There is also a class of errors that Python reports on the wrong line. Consider:

result = (
    first_value +
    second_value
    third_value
)

Python reports the error on line 4, where third_value appears. But the actual mistake is on line 3: a missing + between second_value and third_value. The reported line is where Python noticed the problem, not where the problem began. When a syntax error seems to point at a line that looks completely fine, check the line above it.