Questions: Debugging Basics

Question 1

A Python program crashes with 'IndexError: list index out of range' on line 47. A student goes directly to line 47 and fixes the index access, but the bug persists. What is the most likely explanation?

• A. The student forgot to save the file before re-running
• B. IndexError cannot be fixed by changing the index — a different data structure is needed
• C. The error message is unreliable and the real crash site is elsewhere
• D. Line 47 is where bad data arrived and crashed, but the bug that created the bad data is earlier in the code

Answer: (D)

Runtime error messages point to where the program crashed, not necessarily where the bug originated. Bad data can be created many lines or function calls earlier and only cause a crash when it's finally used in an incompatible way. Reading the full stack trace — which shows the chain of calls leading to the crash — and forming a hypothesis about where the corrupted value was first produced is more effective than patching only the crash site.

Question 2

A programmer's function produces wrong output. She adds a print statement just before the function returns and sees the value looks correct at that point. What should she conclude?

• A. The function's algorithm is definitely wrong and needs to be rewritten
• B. The print confirms the bug is in this function; she should add more prints inside it
• C. The function appears correct; the bug is likely in how the return value is used downstream
• D. Print debugging is unreliable and she should switch to a debugger immediately

Answer: (C)

Print debugging works by narrowing down where the discrepancy first appears. If the value is correct at the return point, the function is not corrupting it — the bug is downstream, in whoever calls this function and uses its result. The print has successfully ruled out this function as the source. The next step is to check how the return value is handled by the calling code.

Question 3

When reading a Python stack trace, the most useful information about the root cause is usually found on the last line printed.

• T. True
• F. False

Answer: False

The last line shows the error type and the crash site — what went wrong and where execution stopped. But the earlier lines in the traceback show the chain of function calls that led there. The real bug is often several calls back, where bad data was first created and then passed along until it eventually caused a crash. Reading only the last line is one of the most common beginner debugging mistakes: it addresses the symptom but misses the cause.

Question 4

A logic error is harder to detect than a syntax error because the program runs to completion and only reveals itself through wrong output, not a crash.

• T. True
• F. False

Answer: True

Syntax errors are caught before the program even runs — the interpreter refuses to execute. Runtime errors crash the program and produce an error message pointing to the failure. Logic errors are the sneakiest: the program executes successfully from start to finish and produces output, but the output is wrong. There is no error message, no crash, and no obvious indicator of where the reasoning went astray. Detecting them requires knowing what the correct output should be and systematically tracing where the program's actual behavior diverges from expected behavior.

Question 5

Why is forming a hypothesis before changing code the habit that separates effective debugging from ineffective debugging?

Model answer: Without a hypothesis, code changes are random guesses — they might accidentally fix a symptom while leaving the root cause intact, or introduce new bugs. A hypothesis ('I think the loop runs one extra iteration because the condition should be < not <=') is a testable prediction: if it's correct, I'd expect the variable to equal X at this breakpoint. When confirmed, you've found the bug and understand why the fix works. When refuted, you've learned something and can form a better hypothesis. Random changes teach you nothing about your program and often make things worse.

The scientific method — observe, hypothesize, test, revise — maps directly onto debugging. Good debuggers form explicit predictions and then design tests (print statements, breakpoints, edge-case inputs) that would confirm or disprove them. This systematic approach converts an intimidating problem ('my program is wrong somewhere') into a series of focused, answerable questions about specific variables at specific points in execution.