1.4 Identifying and Correcting Errors

What you need to know

• Syntax error: the code violates the rules of the language (missing parenthesis, misspelled keyword). The program cannot run at all until it's fixed.
• Logic error: the code runs and finishes, but the result is wrong because the reasoning is flawed — e.g., using < where ≤ was intended, or an off-by-one loop bound.
• Run-time error: the code is syntactically valid but hits a problem while executing — dividing by zero, accessing index 0 or index beyond a list's length — and stops.
• Overflow error: the result of a calculation is too large for the computer to store in the fixed number of bits available for it. Related: round-off error, where real numbers can't be represented exactly.
• Testing means running the program with chosen inputs and comparing the actual output to the expected output. Good test cases include normal values, boundary values, and invalid or empty inputs.
• Debugging is the process of finding and fixing errors. Common strategies: hand-tracing (executing line by line on paper with a variable table), adding extra output statements to see intermediate values, and testing with different inputs to isolate the failing case.
• Some errors can be caught before running (syntax); most logic errors are only found by testing.

Worked example

count ← 0
FOR EACH score IN scores
{
    IF (score > 90)
    {
        count ← count + 1
    }
}
DISPLAY(count)

Intended purpose: count scores of 90 or above. This runs with no error message, but a score of exactly 90 isn't counted because the condition uses > instead of ≥. That's a logic error. You'd only catch it by testing with a score of 90 — which is why boundary values belong in every test set.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• The CED gives exactly four error types: syntax, logic, run-time, and overflow. Overflow is its own category — a number too large for the storage available. Some resources fold it into run-time errors; the exam lists it separately.
• A subtle point: a logic error can produce correct output for some inputs and wrong output for others. That's why it's dangerous — testing with one input can miss it. Boundary values (0, negative, empty, max) are where logic errors hide.
• Testing has a specific shape in the CED: choose inputs, predict the expected output, run, compare. If they don't match, there's an error. The prediction step is what students skip — without it, you can't tell whether output is right.
• Debugging by hand-tracing means executing the code mentally or on paper with a specific input, recording variable values at each step. It's slow but reliable, and it's the method the exam's own code-analysis questions require you to use anyway.
• Extra output statements (temporary DISPLAY calls showing a variable's value mid-program) are a legitimate, CED-named debugging technique. Remove them when done.
• Programs with syntax errors cannot be run, so their behavior is never "wrong output" — it's "no output." A question describing a program that ran and did something has ruled out syntax errors by definition.

Mistakes that cost points

• Calling a crash a logic error. If the program stops with an error message partway, it's run-time. Logic errors run to completion. The word "terminates unexpectedly" or "crashes" means run-time.
• Calling a wrong answer a syntax error. Syntax errors prevent running. If the program produced a value, its syntax was fine.
• Testing only typical inputs. The exam's "which test case would reveal the error" questions almost always have the answer at a boundary — the empty list, the value exactly equal to the threshold, zero.
• Assuming a program that ran without errors is correct. No error message means no syntax or run-time error. It says nothing about logic.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.