Skip to main content
CSP LabBy Educator Today
AP CSP course

C07 · Topic 1.4 · 40 minutes · CRD-2.I, CRD-2.J

Kinds of programme errors

By the end you can:

  • Distinguish syntax, execution and logic issues.
  • Compare observed behaviour with a specification.
  • Isolate a cause using a trace.

Before this lesson: topics 3.1, 3.6.

Logic error
Code runs but its behaviour does not meet the intended rule.
Test case
A specified input and expected output or behaviour used to check a requirement.

Understand

An error can prevent code from being interpreted, occur during execution, or produce the wrong result while the programme runs. Classify the evidence rather than assuming every failure is the same. A displayed answer is not proof that the computation meets its intended rule.

Start debugging with a clear specification, a reproducible input, the expected result and the observed result. Trace the values and branches that connect the input to the discrepancy. Fixing a symptom without finding its cause can leave the same defect elsewhere.

Worked example

A counter should count values at least 5 in[5,5,1], but its condition is value>5.

  1. Specification: both 5s qualify, so expected count 2.
  2. Observed strict comparison rejects both, producing 0.
  3. The programme can run; the defect is a boundary logic error, repaired by≥for this requirement.

Explore each concept

Choose a concept, change its inputs and follow the explanation. Each example models the stated rule or scenario; completing it is practice rather than evidence of mastery.

  • Error classification
  • Expected versus observed output
  • Distinguishing tests and regression
Open this example on its own

Change it · step through · explain

Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.

Ready · Make a prediction

Ready to explore: Locate syntax, execution and logic errors
  1. FaultlogicWaiting
  2. Boundary test value (0–100)5Waiting

Ready to explore: Locate syntax, execution and logic errors

Why: Change an input, predict the first effect, then advance one step.

Try this: Change one input or choose another listed case. Predict the effect, reset and compare the states and governing rule.

Step through and experiment

Change it · step through · explain

Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.

Ready · Make a prediction

Ready to experiment
  1. Input 15,5,1Waiting
  2. Input 25Waiting
  3. Input 3boundaryWaiting

Ready to experiment

Why: Predict the first change, then advance one step.

Try this: Try repeated boundary values, no matches and an empty list.

Check a misconception

Claim: If the programme runs, it cannot contain an error.

Executable statements can still implement the wrong rule.

Guided practice

Give expected and observed results for[5]with the strict comparison.

Work with a partner. Make a prediction, compare your reasoning, then identify the rule that supports your answer.

Independent transfer

A second version resets count inside every iteration. Trace[6,6]with minimum 5.

Exit check

Why must a repair be checked against a requirement?

Write your reasoning before comparing with a classmate. If your teacher assigned this task, submit it through My classes to save your work and receive feedback.

Check yourself

  1. Question 1 of 2A counter runs but excludes a valid endpoint. What is this evidence of?

    Select one answer.

  2. Question 2 of 2Which TWO facts make a bug report reproducible?

    Select exactly two answers (0 of 2 selected).

Your practice so far

Check an answer to see its rationale.

Teacher guidance and scoring