In AP Computer Science A, an off by one error is a logic error where an iterative statement (like a while loop) executes one time too many or one time too few, usually because the loop's Boolean condition or counter update is slightly wrong (EK 2.7.A.4).
An off by one error happens when a loop repeats one extra time or one too few times. The code compiles fine and runs fine. It just produces the wrong answer because the repetition count is off by exactly one. That's what makes it sneaky: there's no error message, only a result that's slightly wrong.
The usual culprit is the boundary of the loop. Maybe you wrote count <= 10 when you needed count < 10, or you initialized your counter at 0 when the logic assumed 1, or you updated the counter before using it instead of after. The CED calls this out directly in EK 2.7.A.4, right alongside infinite loops, as one of the classic ways iteration goes wrong. A quick gut-check that catches most of them is the fencepost idea. If you put up 10 feet of fence with a post every foot, you need 11 posts, not 10. Loops have the same edge problem, and forgetting it is exactly how you end up one iteration off.
Off by one errors live in Topic 2.7 (While Loops) in Unit 2: Selection and Iteration, under learning objective AP Comp Sci A 2.7.A, which asks you to identify when iteration is needed and recognize when it goes wrong. Essential knowledge EK 2.7.A.4 names the error explicitly, so it's fair game on the exam by name.
The bigger reason it matters is that loop boundaries follow you through the entire course. Every time you traverse an array, an ArrayList, or a 2D array in later units, you're setting loop bounds again, and an off by one mistake there either gives a wrong answer or crashes with an out-of-bounds exception. Getting comfortable checking boundaries now, in Unit 2, pays off on basically every FRQ that uses a loop.
Keep studying AP® Computer Science A Unit 2
While Loops (Unit 2)
Off by one errors are defined in terms of while loops. Per EK 2.7.B.1, the Boolean expression is checked before every iteration, including the first, so the exact comparison operator (< vs <=) decides whether the loop runs the right number of times or one off.
Infinite Loops (Unit 2)
EK 2.7.A.2 and EK 2.7.A.4 sit side by side as the two classic loop bugs. Both come from a bad condition or a bad counter update. The difference is severity. An infinite loop never stops, while an off by one loop stops at the wrong time.
Array and ArrayList Traversal (Unit 4)
This is where off by one errors get expensive. Array indices run from 0 to length - 1, so writing i <= arr.length doesn't just give a wrong answer, it throws an ArrayIndexOutOfBoundsException. The Unit 2 habit of checking your loop bounds becomes survival skill in Unit 4.
Simulations like runSimulations (Unit 2)
Loop-driven simulation methods are a common exam setup. If a method is supposed to run a process exactly n times and your counter logic is off, every result downstream is wrong. Counting iterations precisely is the whole game.
Off by one errors show up most often in trace-the-code multiple choice questions. A typical stem gives you a while loop and asks what gets printed, what a variable equals after the loop, or how many times the body executes. The wrong answer choices are almost always the off by one neighbors of the correct answer (one more and one less), so the question is really testing whether you traced the boundary iteration correctly. Another common format asks which change to the code would fix or cause an off by one error.
No released FRQ uses the phrase verbatim, but off by one mistakes are one of the most common ways to lose FRQ points on any method that loops. Your defense is to hand-trace the first iteration and the last iteration. Ask yourself two questions: does the body run when the counter is at its starting value, and does it run when the counter hits the boundary? If both edges check out, the middle takes care of itself.
Both are loop bugs caused by a faulty condition or counter, but they fail differently. An infinite loop's Boolean expression always evaluates to true (EK 2.7.A.2), so the loop never terminates and the program hangs. An off by one error's loop does terminate, just one iteration early or late, so the program finishes with a quietly wrong result. On MCQs, ask whether the loop variable ever makes the condition false. If yes, you're looking at a count problem, not an infinite loop.
An off by one error means a loop runs exactly one time too many or one time too few, and the CED names it explicitly in EK 2.7.A.4 under Topic 2.7.
It's a logic error, not a syntax error, so the code compiles and runs but produces a wrong result with no error message.
The most common causes are using < when you need <= (or vice versa), starting the counter at the wrong value, or updating the counter in the wrong place.
To catch it, trace the first and last iterations by hand and check whether the loop body runs at each boundary.
In Unit 4, an off by one error on an array index usually throws an ArrayIndexOutOfBoundsException, since valid indices go from 0 to length - 1.
MCQ answer choices are often built around off by one traps, so when your traced answer is one away from a choice, re-check the boundary iteration before picking.
It's an error where an iterative statement, like a while loop, executes one time too many or one time too few. The CED defines it in EK 2.7.A.4 under Topic 2.7 (While Loops).
It's a logic error. The code compiles and runs without complaint, but the repetition count is wrong by one, so the output is incorrect. That's why hand-tracing loops is the only reliable way to catch it.
An infinite loop never terminates because its Boolean condition always evaluates to true (EK 2.7.A.2). An off by one loop does terminate, just after one extra or one missing iteration. One hangs your program, the other quietly gives a wrong answer.
No. In Unit 2, a plain counting loop just produces a wrong value with no crash at all. It only crashes when the bad count becomes an invalid array index in Unit 4, which throws an ArrayIndexOutOfBoundsException.
Check the two edges. Trace what happens on the very first iteration and the very last one, paying attention to whether your condition uses < or <=. For arrays, remember valid indices run from 0 to length - 1, so the condition is almost always i < arr.length.
Connect this key term to the AP exam workflow: review the course, practice questions, and check related study tools.
Review units, study guides, and course resources.
Check this vocabulary in multiple-choice context.
Apply key concepts in written AP responses.
Estimate the exam score you are working toward.
Review the highest-yield facts before practice.
Put the full course together before test day.