AP CSP 1.4 Identifying and Correcting Errors | Debugging and Testing
Identifying and Correcting Errors
After this lesson, you will be able to:
- Distinguish logic, syntax, run-time, and overflow errors by how each one shows up
- Explain why a program with a logic error still runs while a syntax error stops it from running
- Design test cases that include typical, boundary, and invalid inputs to expose errors
- Apply debugging strategies such as hand-tracing, adding display statements, and isolating sections of code
- Describe how documentation and collaboration make errors easier to find and correct
A program that calculates the average of a class quiz runs with no red error messages, prints a clean number, and looks finished. But when a student scores a perfect 100 on every quiz, the program reports an average of 91. Nothing crashed, nothing was underlined in red, and yet the answer is wrong. What kind of error is this, and what single test case would have caught it before the program shipped?
Four Kinds of Errors
An error is any flaw that keeps a program from doing what it should. The AP CSP framework names four types, and the exam expects you to tell them apart by how they show up, not just by their definitions. The single most useful question to ask is: does the program still run?
| Error type | Does it run? | Example |
|---|---|---|
| Syntax error | No. It violates the rules of the language, so the program will not run at all. | A missing quotation mark or an unmatched parenthesis, such as DISPLAY("hi)
|
| Logic error | Yes. It runs, but produces incorrect or unintended output. | Using + where you meant *, so the total is wrong but no error is shown |
| Run-time error | It starts, then fails while running. | Dividing by zero, or reading a list value that does not exist |
| Overflow error | It runs, then breaks or wraps. | A number grows too large to fit in the space allotted to represent it |
Read that table carefully. A syntax error is caught before the program even starts because the language cannot understand it. A logic error is the sneakiest because everything looks fine, the program runs to completion, and only the answer is wrong. A run-time error happens partway through, often because of a specific input like a zero or a missing value. An overflow error is a special case where a value is simply too big for the number of bits allotted to store it.
If a program runs and finishes but the output is wrong, the answer is almost always a logic error. If the program will not run at all, it is a syntax error. If it runs for a while and then stops, look for a run-time error tied to a specific input. Anchor your choice to whether and when the program runs.
Testing: Trying to Break Your Own Program
Testing is running a program with a variety of inputs to find errors and check that it behaves correctly. The goal is not to confirm that the program works on the one input you already tried; it is to actively hunt for the input that makes it fail. Good testing covers three kinds of input:
- Typical inputs, the ordinary values a user is expected to enter, to confirm normal behavior.
- Boundary (edge) cases, the extremes and just-past-extremes such as zero, an empty list, a maximum value, or the very first and very last items. Most bugs hide here.
- Invalid inputs, values the program should reject, such as a letter where a number is expected or a negative age, to check that the program handles bad data gracefully.
The quiz-average program from the hook is a perfect example: it passed on a mix of scores but failed on the boundary case of all perfect scores. A single well-chosen edge case would have exposed the logic error immediately.
"The program worked when I ran it, so it is correct." Running a program once with one friendly input is not testing. A program can pass every typical case and still fail on an empty list, a zero, or the last element of a range. If a question offers "test it with one normal input" versus "test it with typical, boundary, and invalid inputs," the thorough option is the right one.
Debugging: Finding and Fixing the Problem
Debugging is the process of finding and correcting errors. Testing tells you that something is wrong; debugging is how you locate where and fix it. The framework expects you to know several concrete strategies, not just the word "debug":
- Hand-tracing (tracing code by hand): stepping through the program line by line on paper, tracking each variable's value, to see where reality diverges from what you expected.
- Adding display or print statements to reveal intermediate values while the program runs, so you can watch a variable change and spot the moment it goes wrong.
- Testing sections in isolation: running one procedure or block by itself, apart from the rest, to confirm that piece works before trusting the whole.
- Commenting out code to temporarily remove a suspect section and see whether the problem disappears, which narrows down where the bug lives.
- Studying the error message: a run-time or syntax error usually reports a line number and a description that points you straight at the trouble.
Consider a loop that is supposed to add up a list but reports a total that is always one item short:
total <- 0
FOR EACH n IN [3, 5, 8]
{
total <- n
}
DISPLAY(total)
Hand-tracing exposes the bug at once: each pass replaces total instead of adding to it, so the program prints 8 rather than 16. The fix is total <- total + n. This is a classic logic error, invisible until you trace the values, and a display statement inside the loop would have made it obvious.
Documentation and collaboration are debugging aids, not just nice-to-haves. Clear comments and a teammate reviewing your code (a navigator, from Topic 1.1) make errors easier to find because a second reader with fresh eyes catches assumptions the author cannot see. Expect the exam to credit "add a comment / get a second reader" as a legitimate error-reduction strategy.
How This Shows Up on the Create Performance Task
The Create Performance Task is completed individually under current AP rules, so the program and the written responses must be your own. Topic 1.4 is central to it. Your program must include a call to a student-developed procedure, and the written responses ask you to describe how that procedure works and how you know your program behaves correctly. That is a testing-and-debugging story.
Specifically, you should test your program with a variety of inputs (including edge cases such as empty input, the smallest and largest values, and invalid entries) and be ready to explain in writing how you identified and corrected errors, or how the program handles unexpected behavior. Reviewers reward responses that show you traced or tested the program rather than just claiming it works. When you describe your procedure and the two calls that produce different results, you are demonstrating exactly the testing thinking this lesson teaches. Keep clear comments in your code so your written explanation matches what the program actually does.
Get a free AP CSP question every day
Join 3,000+ students. Daily practice, study tips, and exam strategies.
A programmer writes a line of code but forgets to close a set of parentheses. When they try to run the program, it will not start at all and no output is produced. Which type of error is this?
The procedure below is intended to return the sum of the numbers in the list. Study it, then choose the best description of the error.
PROCEDURE sumList(nums)
{
total <- 0
FOR EACH n IN nums
{
total <- n
}
RETURN total
}A student wrote a program that computes the average score of a list of quiz grades and only tested it once, with the list [80, 90, 100], getting a reasonable result. Which additional test case is most likely to reveal a hidden error in the program?
Consider these statements about errors in a program:
- I. A syntax error prevents a program from running at all.
- II. A logic error can be present in a program that runs to completion and produces output.
- III. A run-time error is always detected before the program begins executing.
A long program produces an incorrect final result but does not crash. A programmer wants to find which section is responsible without rewriting everything. Which approach best isolates the faulty section?
A program repeatedly doubles a whole number stored in a fixed amount of memory. After many doublings the value suddenly becomes negative or wildly incorrect, even though the code and inputs are valid. Which type of error best explains this behavior?
🐛 Bug Squasher
AP CSP 1.4 • Identify and correct errors: syntax, logic, runtime, and overflow.
How to play: read the buggy code, first CLASSIFY the error type, then pick the FIX. Beat the timer and build a streak!
Frequently Asked Questions
🔗 Continue studying
Errors and testing are where students most often confuse vocabulary, so drill the runs-but-wrong versus will-not-run distinction relentlessly. Give buggy code and have students classify the error, propose a test case that would catch it, and name a debugging strategy to locate it. The Superpack includes a bug-classification sorting deck, an edge-case testing worksheet, and hand-tracing practice with answer keys. View what's included →
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]