1.4 Identifying and Correcting Errors

Identifying and correcting errors means spotting bugs in a program, naming what kind of error they are, and fixing them. The four error types to know are logic, syntax, run time, and overflow errors, and the main fixing tools are test cases, hand tracing, visualizations, debuggers, and extra output statements. For AP Computer Science Principles, use test inputs and tracing to explain why code behaves differently from what the programmer intended.

Why This Matters for the AP Computer Science Principles Exam

This topic shows up directly in multiple-choice questions that hand you a code segment and ask you to find the error, predict what the buggy code outputs, or choose the fix. You will trace through pseudocode line by line and reason about what each input should produce.

It also matters for the Create performance task. You develop your own program, so you will run into real bugs and need to test, debug, and refine your code until it behaves the way you expect. Knowing how to choose useful inputs and trace your own logic makes that process faster.

more resources to help you study

practice multiple choiceFRQ practice & scoringcheatsheetsscore calculator

Key Takeaways

• Know the four error types cold: logic, syntax, run-time, and overflow. Be able to tell them apart from a short description or code sample.
• A syntax error breaks the rules of the language; a logic error runs but gives wrong results; a run-time error crashes during execution; an overflow error happens when a number is outside the allowed range.
• Use these tools to find and fix errors: test cases, hand tracing, visualizations, debuggers, and adding extra output statements.
• Testing uses defined inputs to check that a program produces the expected output, then you revise based on the results.
• Pick test inputs at or just beyond the minimum and maximum extremes, since edge values are where bugs hide.
• You need clear program requirements before you can choose good test inputs.

The Four Error Types

These four error types come up the most, and the exam expects you to tell them apart.

Syntax errors happen when you break the rules of the programming language, like a missing parenthesis, a misspelled keyword, or bad punctuation. The program usually will not run at all. These are often the easiest to catch because many code editors highlight them for you.

Logic errors are mistakes in the program's logic that make it behave incorrectly or unexpectedly. The code runs fine, but the output is wrong. For example, a program that should multiply two numbers but returns the wrong product has a logic error.

Run-time errors occur while the program is running. The program starts normally, but something goes wrong during execution. A classic example is a division program that crashes when it tries to divide by zero. Different programming languages define their own run-time errors, so the same bug can behave differently depending on the language.

Overflow errors happen when a computer tries to handle a number outside its defined range of values, usually a number too large for it to store.

When an error stops a program, you often get an error message. Sometimes the message clearly names the problem, but error messages are not always helpful, so it pays to have several debugging methods ready.

Ways to Find and Fix Errors

No single method works for every bug. Mix and match these based on what you need.

• Test cases: Run your program with chosen inputs and compare the actual output to the expected output. Testing at different points during execution helps narrow down where things break.
• Hand tracing: Manually track each variable's value as you step through the code, often using a chart. This works well on short programs like the ones on the exam, but gets hard as code grows longer.
• Visualizations: Use a tool that shows how your code runs step by step. Helpful for understanding flow, though you will not be required to use one on the exam or for the Create task.
• Debuggers: Programs built specifically to help you locate bugs.
• Adding extra output statements: Print the values of variables at key spots so you can see the "invisible" steps that do not normally show up as output.

</>Code
PROCEDURE countNumOccurences(myList, val)
    count ← 0
    FOR EACH item IN myList
        IF (item = val)
            count ← count + 1
    RETURN (count)

Adding a print statement right after each IF check, for example, would let you watch count change and confirm the loop is working.

Testing Strategies

Testing is the process of checking that your code does what it should. It sounds simple, but it is one of the harder parts of programming.

Common Testing Challenges

• Complexity: The longer and more complicated the code, the harder it is to test thoroughly.
• Limited time and resources: There are often more failure scenarios than you can realistically check.
• Unclear requirements: Before testing, you need to know your program requirements, meaning exactly what the program should do and what inputs it needs. A program that adds two numbers needs two numbers to work.
• Not understanding your own code: If you are unsure what a section does or how sections interact, debugging it is much harder.

Good Testing Practices

• A test case is a set of inputs paired with the expected output. For example, inputs 5 and 3 into an adding program should produce 8.
• Writing test cases before you write the program helps you stay clear on what you are trying to build.
• Test boundary values, the inputs at or just beyond the minimum and maximum limits, because that is where errors are most likely. If a program only accepts values less than 9, you would check 8 and 10.
• Use the program requirements to decide which defined inputs make sense to test.

How to Use This on the AP Computer Science Principles Exam

MCQ

You will get a short code segment and a task like "find the error," "what does this output," or "which change fixes the bug." Read the program's purpose first so you know what correct behavior looks like, then trace carefully.

Code Tracing

Pick a small test input and walk through the code line by line, tracking each variable. Watch loop boundaries closely, since misplaced statements inside or outside a loop are a common trap.

Worked example: suppose a procedure should return how many times val appears in a list.

</>Code
PROCEDURE countNumOccurences(myList, val)
    FOR EACH item IN myList
        count ← 0
        IF (item = val)
            count ← count + 1
    RETURN (count)

Trace it with the list [5, 2, 3, 5] and val set to 5. The correct answer should be 2. As you step through, count resets to 0 at the start of every loop pass, so by the end it only reflects the last item. The fix is to move count ← 0 out of the loop so it runs once before the loop begins. After that change, count keeps its running total across all items.

Create Task

When building your own program, treat bugs as expected. Write test cases for normal inputs and edge values, hand trace any section that misbehaves, and add output statements to confirm the hidden steps work. Revise based on what your tests show.

Common Trap

Resetting a counter or accumulator inside a loop instead of before it. The code will run without crashing, which makes it a logic error, not a syntax or run-time error.

Common Misconceptions

• "Errors mean you are bad at coding." Bugs happen to everyone, including professionals. Debugging is a normal, expected part of the process, which is why so many software updates are just bug fixes.
• "If the program runs, it is correct." A program with a logic error runs fine but produces wrong results. Running is not the same as being correct.
• "All errors crash the program." Only some do. Syntax errors usually stop it from running, run-time errors crash it during execution, but logic errors let it run and just give wrong output.
• "Overflow and logic errors are the same." An overflow error is specifically about a number falling outside the allowed range. A logic error is a flaw in the program's reasoning.
• "You only need to test typical inputs." The most useful test inputs are at or just beyond the minimum and maximum extremes, since edge values are where bugs often appear.
• "You need program requirements only at the start." You need clear requirements to choose good test inputs, so they matter throughout testing, not just during planning.

Related AP Computer Science Principles Guides

• 1.1 Collaboration
• 1.3 Program Design and Development
• 1.2 Program Function and Purpose
• Big Idea 1 Overview: Creative Development