Topic 1.4: Identifying and Correcting Errors | AP CSP Big Idea 1 | APCSExamPrep.com

AP CSP Course› Big Idea 1› 1.4 Identifying and Correcting Errors
1.4
Big Idea 1 • Creative Development • Final Topic

Identifying and Correcting Errors

🕐 ~20 min FREE 📖 4 MCQ practice questions 🎮 1 interactive game CRD-2.I • CRD-2.J
1.1
Collaboration
1.2
Function &
Purpose
1.3
Design &
Dev
1.4
Errors

After this lesson, you will be able to:

  • Identify and distinguish between the four types of programming errors: logic, syntax, run-time, and overflow
  • Apply debugging strategies including test cases, hand tracing, visualizations, debuggers, and extra output statements
  • Design test cases that cover expected values and edge cases at input extremes
  • Explain why programs that run without crashing can still contain errors
📈 Exam weight: Topic 1.4 is one of the highest-frequency Big Idea 1 topics on the AP exam. The four error types are tested in almost every exam year. Expect 2–3 questions asking you to identify an error type from a code example or description.
💡 Think about this first

In 1999, NASA lost a $327 million Mars orbiter because one engineering team used metric units and another used imperial units. The software ran perfectly — no crashes, no error messages. It just silently calculated the wrong trajectory. That's a logic error at $327 million scale. Understanding the difference between 'the program ran' and 'the program was correct' is the core insight of this topic.

The Four Types of Errors

The AP CSP CED defines four specific types of programming errors. You must be able to identify each type from a description or code example.

1. Logic Error

A logic error is a mistake in the algorithm or program that causes it to behave incorrectly or unexpectedly. Programs with logic errors can still run — they just produce wrong results. This makes logic errors the hardest to catch: there's no error message telling you something is wrong.

Example: A program that calculates a student's letter grade uses > instead of >= for the boundary between A and B. The program runs, assigns grades, and produces output — but every student right at the boundary gets the wrong grade.

2. Syntax Error

A syntax error is a mistake where the rules of the programming language are not followed. The program typically cannot run at all until the syntax error is fixed. The interpreter or compiler catches these before execution.

Example: Writing if x = 5 instead of if x == 5 in Python. The language doesn't understand the single equals in this context and refuses to run the program.

3. Run-Time Error

A run-time error is a mistake that occurs during execution — after the program has started running. The program may run fine until it hits a specific condition, then crash or produce unexpected behavior. Each programming language defines its own run-time errors.

Example: A program that divides a number by a user-provided value runs fine until the user enters 0. Division by zero causes a run-time error that crashes the program.

4. Overflow Error

An overflow error occurs when a computer attempts to handle a number outside the defined range of values for a data type. Computers store numbers in fixed amounts of memory, which limits the size of numbers they can represent.

Example: If a system uses 8 bits to store a non-negative integer, it can represent 0–255. Adding 1 to 255 produces an overflow — the result wraps around or causes an error because 256 can't be stored in 8 bits.

🎯 Exam tip

The most commonly confused pair is logic errors vs. run-time errors. Remember: a logic error means the program runs but produces wrong results. A run-time error means the program crashes during execution. If the program runs to completion but gives the wrong answer — that's a logic error.

Debugging Strategies

Finding and fixing errors requires systematic approaches. The CED identifies five effective debugging strategies:

1. Test Cases

A test case is a defined input used to check whether a program produces the expected output. Good test cases cover:

  • Typical values in the middle of the input range
  • Boundary values at or just beyond the minimum and maximum of valid input
  • Edge cases that might trigger unexpected behavior

For a function that accepts integers 1–100: test with 1, 100, 50, 0, and 101. Testing only with 50 would miss most bugs.

2. Hand Tracing

Hand tracing means manually following the program's logic step by step on paper, tracking the value of each variable through each line. It's slow but thorough — and it's the method that reveals logic errors that hide from automated tools.

3. Visualizations

Visualizations are tools that display the state of a program's variables and data structures during execution. Watching a sorting algorithm rearrange an array in real time, for example, makes it immediately obvious when the algorithm is wrong.

4. Debuggers

A debugger is a software tool that pauses execution at specified points (called breakpoints) and allows the developer to inspect the current state of the program — variable values, the call stack, which line is executing. Most modern development environments include built-in debuggers.

5. Adding Extra Output Statements

Adding temporary DISPLAY or print statements throughout a program to show variable values at key points is one of the simplest and most effective debugging techniques. Once the bug is found and fixed, the extra statements are removed.

⚠ Common exam trap

The exam sometimes asks which debugging strategy is 'most appropriate' for a given scenario. Remember that hand tracing and test cases are used to find logic errors. Debuggers are used when you need to inspect program state during execution. Extra output statements work anywhere but are especially useful when you can't use a debugger.

Key Vocabulary

Term AP Definition Plain English
Logic error A mistake in the algorithm causing incorrect or unexpected behavior; program still runs The program works but does the wrong thing
Syntax error A violation of programming language rules; program typically cannot run The program breaks the grammar rules of the language
Run-time error An error that occurs during execution; program crashes or behaves unexpectedly The program starts fine but crashes when it hits a problem
Overflow error An error when a number exceeds the defined range of values a system can handle The number is too big (or too small) for the computer to store
Test case A defined input used to verify a program produces expected output A specific test you run to check if the program works correctly
Hand tracing Manually following program logic step by step, tracking variable values Walking through the code yourself on paper to find bugs
Debugger A tool that pauses execution and allows inspection of program state A tool that lets you freeze a running program and look inside it
📋 Create Task connection

The concepts in this topic connect directly to your Create Performance Task. Understanding program purpose, iterative design, and how to identify errors will help you write stronger CPT responses. See the Create Task module →

🅾
MCQ Practice
4 questions • AP exam difficulty • Instant feedback
Question 1 of 4
A student writes a program to calculate whether a year is a leap year. The program runs without any errors or crashes, but it incorrectly identifies 1900 as a leap year (1900 is not a leap year under the Gregorian calendar). Which type of error does this program contain?
Incorrect. Syntax errors prevent a program from running at all — they are caught before execution. This program ran successfully, so there is no syntax error.
Incorrect. Run-time errors cause programs to crash or behave unexpectedly during execution. This program ran to completion and produced output. The issue is that the output is wrong, which is the definition of a logic error.
Correct. The program runs without crashing and produces output — but the output is incorrect because the algorithm is flawed. This is exactly the definition of a logic error: incorrect or unexpected behavior while the program still executes.
Incorrect. An overflow error involves numbers exceeding the storage range, not incorrect algorithm logic. A year value like 1900 is well within any integer range.
Question 2 of 4
A developer is testing a function that accepts an integer between 1 and 100 (inclusive) and returns its square root. Which set of test inputs BEST follows the CED's guidance on effective test cases?
Incorrect. Testing only typical middle values misses edge cases at the input boundaries. The CED specifically states that test inputs should cover values at or just beyond the extremes of input data.
Incorrect. A single value cannot reveal boundary bugs, off-by-one errors, or edge case failures. The CED requires testing across the range, especially at extremes.
Correct. This covers: the minimum valid input (1), the maximum valid input (100), a middle value (50), and values just outside the valid range (0 and 101). The CED states test cases should demonstrate different expected outcomes at or just beyond the extremes of input data.
Incorrect. Testing all even numbers provides massive redundancy (50 tests doing the same thing) while still missing the critical boundary cases and out-of-range inputs.
Question 3 of 4
A program stores user ages as 8-bit unsigned integers (range: 0–255). A user enters their age as 300. Which type of error will occur?
Incorrect. A logic error involves incorrect algorithm behavior, not a number exceeding storage limits. The issue here is specifically about the data type's capacity, not the algorithm's correctness.
Incorrect. 300 is a valid integer syntactically. The problem is not with the language rules but with the storage limitation of the specific data type being used.
Incorrect. While overflow can sometimes cause crashes, the defining characteristic of an overflow error is that the number exceeds the defined range — not simply that the program crashes.
Correct. An overflow error occurs when a computer attempts to handle a number outside the defined range of values. 300 cannot be stored in an 8-bit unsigned integer (max 255), making this a textbook overflow error.
Question 4 of 4
A developer suspects a logic error in a complex function that calculates shipping costs. She wants to understand exactly what value each variable holds at each step of the calculation. Which debugging strategy is MOST directly suited to this goal?
Incorrect. Syntax checking verifies language rules, not variable values during logic execution. The program is presumably already running (it produces results), so syntax is not the issue.
Correct. Hand tracing is specifically designed for this: following a program's logic step by step, tracking variable values through each line. When you need to know exactly what each variable holds at each stage of a calculation, hand tracing gives you the most direct visibility.
Partially useful but not the most direct approach. Boundary testing helps find errors at input extremes but doesn't directly reveal the variable values during intermediate calculation steps.
Incorrect. Documentation describes intended behavior but doesn't show actual variable values during execution. It could help identify what the function is supposed to do, but not diagnose what it's actually doing.
🎮 Lesson Game
Error Type Identifier
Read each scenario. Identify the type of error or debugging strategy being described.
0
Score
1
Question
6
Total
0
Streak 🔥
Scenario 1 of 6

Loading...

out of 6

Frequently Asked Questions

Logic error: program runs, produces wrong results (algorithm is wrong). Syntax error: program won't run because language rules are broken. Run-time error: program runs but crashes during execution. Overflow error: a number exceeds the data type's defined range. The key distinction: if it runs and gives wrong answers — logic. If it won't run at all — syntax. If it crashes mid-run — run-time. If a number is too big to store — overflow.
Yes — and this is one of the most important ideas in Topic 1.4. A program that runs without crashing and produces output can still be completely wrong. If the algorithm is incorrect, the program will produce incorrect results silently. The $327 million Mars orbiter loss is a real-world example: the program ran fine but used the wrong unit system.
The CED states test inputs should cover different expected outcomes at or just beyond the extremes of input data — meaning boundary values. For a function accepting 1–100: test 1, 100, a middle value like 50, and values just outside the range (0 and 101). Testing only middle values misses most real bugs.
Hand tracing is manually following a program's logic step by step, tracking variable values through each line. You do it on paper (or mentally). It's the best strategy for finding logic errors in short segments of code because it shows exactly what each variable holds at each step — which is often where the bug hides.
Error identification appears throughout BI3 (Algorithms & Programming) where you'll trace code, predict output, and fix bugs. The four error types and debugging strategies also appear in the Create Task — you should document how you tested your program and what types of errors you found and corrected. This topic is foundational for the rest of the course.

🔗 Continue studying AP CSP

← Big Idea 1 Hub ← 1.3 Program Design and Development Next: Big Idea 2: Data → Big Idea 2: Data Big Idea 3: Algorithms Create Task Module Daily Practice Questions Full Practice Exam College Board AP CSP ↗ Download CED PDF ↗
📦
AP CSP Teacher Superpack Slides, lesson plans, tests + answer keys for all 5 Big Ideas — $249
Get the Superpack →
🏫
For teachers

The Superpack includes a full lesson plan for this topic with day-by-day pacing, editable slides, student guided notes, and a unit test with answer key covering all of Big Idea 1. View what's included →

← Previous
1.3 Program Design and Development

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.

Typically responds within 24 hours
✓

Message Sent!

Thanks for reaching out. I'll get back to you within 24 hours.

🏫 Welcome, fellow educator!

I offer curriculum resources, practice materials, and study guides designed for AP CS teachers. Let me know what you're looking for — whether it's classroom materials, a guest speaker, or Teachers Pay Teachers resources.

✉

Email

[email protected]

📚

Courses

AP CSA, CSP, & Cybersecurity

⏱

Response Time

Within 24 hours

Prefer email? Reach me directly at [email protected]