In AP Computer Science A, bounds are the valid range of indices for an array: the lower bound is 0 and the upper bound is array.length - 1. Accessing any index outside this range throws an ArrayIndexOutOfBoundsException at runtime.
Bounds are the limits on which indices you're allowed to use when accessing an array. In Java, every array is zero-indexed, so the lower bound is always 0 and the upper bound is always array.length - 1. An array declared as new int[8] has a length of 8, but its valid indices run from 0 to 7. That gap between "length" and "largest valid index" is where most bounds mistakes live.
If your code tries to read or write outside those bounds, like values[8] in an 8-element array, the code still compiles fine. The problem only shows up at runtime, when Java throws an ArrayIndexOutOfBoundsException and the program crashes. The same rule applies to ArrayList (via get and set), to each row and column of a 2D array, and to String indices with charAt. Anywhere there's an index, there are bounds.
Bounds sit at the heart of the array material in AP CSA (arrays in Unit 6, ArrayLists in Unit 7, and 2D arrays in Unit 8). Every traversal you write, whether it's a standard for loop, a reverse loop, or nested loops over a 2D array, depends on getting the loop condition to match the array's bounds exactly. The classic correct pattern is for (int i = 0; i < arr.length; i++). Change < to <= or start at 1 instead of 0, and you've either crashed the program or silently skipped an element. The exam tests this constantly because it's the single most common bug in real student code. If you can spot an off-by-one bounds error in five seconds, you've banked easy points on both the multiple-choice section and the FRQs.
array.length and Array Length (Unit 6)
Bounds and length are two views of the same fact. The length tells you how many elements exist, and the bounds tell you which indices are legal. Length 10 means indices 0 through 9, never 10. Memorize the translation: upper bound equals length minus one.
ArrayIndexOutOfBoundsException (Unit 6)
This is what happens when bounds are violated. It's a runtime exception, not a compile error, so the code looks fine until it actually runs. MCQ answer choices love to test whether you know the difference.
Traverse (Units 6-8)
Traversal is bounds management in action. A forward traversal runs from 0 up to length - 1, a reverse traversal runs from length - 1 down to 0, and a 2D traversal needs correct bounds on both the row loop and the column loop. Nested loops mean two chances for an off-by-one error.
Boundary Checking (Units 6-8)
When an index comes from a calculation, like a neighbor cell in a 2D grid or a frog's position in a simulation, you check it against the bounds before using it. The 2017 Successors FRQ and the 2018 FrogSimulation FRQ both required exactly this kind of guard logic.
Bounds show up two ways. On multiple choice, you'll analyze a code segment and decide whether it runs correctly, skips an element, or throws an ArrayIndexOutOfBoundsException. A loop like for (int i = 1; i <= values.length; i++) is a classic stem because it has two bounds bugs at once (it skips index 0 and then crashes at index length). Practice questions on reversing an array in place or finding a max value hinge entirely on whether the loop bounds are right. On the FRQs, you write the bounds yourself. Array and 2D array questions (like 2017 Q4, which asked you to find a value's position in a 2D grid and then check its "successor") require loops that stay in bounds and, often, explicit checks before accessing a computed index. Graders deduct for out-of-bounds access, so i < arr.length, not i <= arr.length, is worth real points.
Length is a count; bounds are a range of indices. An array with length == 8 holds 8 elements, but because Java starts counting at 0, the valid indices are 0 through 7. Treating the length itself as a valid index is the off-by-one error, and it's the single most tested bounds mistake on the exam. If you ever write arr[arr.length], that's a guaranteed crash.
In Java, the bounds of an array run from index 0 to index array.length - 1, so the length itself is never a valid index.
Accessing an index outside the bounds compiles without error but throws an ArrayIndexOutOfBoundsException when the program runs.
The standard safe traversal is for (int i = 0; i < arr.length; i++), and changing < to <= is the most common off-by-one bug on the exam.
2D arrays have separate bounds for rows and columns, so nested loops give you two places to make an off-by-one mistake.
When an index is computed (like a neighbor cell in a grid), check it against the bounds before using it, because FRQ graders deduct for out-of-bounds access.
Bounds are the valid range of indices for an array: 0 is the lower bound and array.length - 1 is the upper bound. Any index outside that range causes an ArrayIndexOutOfBoundsException at runtime.
No. Code like arr[arr.length] compiles perfectly fine. The error only appears at runtime, when Java throws an ArrayIndexOutOfBoundsException and the program crashes. MCQ answer choices often test exactly this compile-time versus runtime distinction.
Length counts the elements; bounds describe the legal indices. An array of length 8 has indices 0 through 7. Confusing the two produces the off-by-one error, like a loop condition of i <= arr.length instead of i < arr.length.
It has two bounds problems. Starting at i = 1 skips index 0, and the condition i <= values.length lets the loop reach values[values.length], which is out of bounds. The program throws an ArrayIndexOutOfBoundsException on that last iteration.
Yes, and they have two sets: rows run from 0 to length - 1 and columns run from 0 to [0].length - 1 in a row-major rectangular array. FRQs like 2017's Successors question require checking both row and column bounds before accessing a neighboring cell.