IndexOutOfBoundsException is a runtime exception Java throws when code tries to access an index outside the valid range of a list, such as calling get(10) on an ArrayList of size 8; valid indices run from 0 to size() - 1.
An IndexOutOfBoundsException is Java's way of telling you that you asked for a position that doesn't exist. For an ArrayList of size 8, the valid indices are 0 through 7. Call list.get(8) or list.get(-1) and the program crashes at runtime with this exception. It is not a compile-time error. Your code compiles fine and then blows up when it actually runs, which is exactly why it's such a popular trap in AP multiple-choice questions.
The exception shows up whenever you index into an ArrayList with get, set, remove, or add using a number outside the legal range. The classic causes are off-by-one mistakes in loop conditions (writing i <= list.size() instead of i < list.size()) and removing elements while you traverse, which shrinks the list underneath your loop so an index that used to be valid suddenly isn't.
This exception lives in the array and ArrayList traversal units of AP CSA (Units 6-7), where you're expected to trace loops over collections and spot exactly when an index goes out of range. The College Board explicitly expects you to know the bounds rule. For an ArrayList, valid indices are 0 to size() - 1, and crossing that line throws an IndexOutOfBoundsException. Almost every traversal question on the exam is secretly testing whether you've internalized that one fact. If you can look at a loop and say "this loop's last iteration calls get(size()), so it crashes," you've got the skill the exam is checking. It also matters for writing FRQ code, because graders penalize out-of-bounds access in your loops even if everything else is right.
Keep studying AP Computer Science A Unit 4
ArrayIndexOutOfBoundsException (Unit 6)
This is the array-flavored sibling, thrown when you index past arr.length - 1 on a plain array. It's actually a subclass of IndexOutOfBoundsException, so the two errors describe the same mistake on two different data structures. Arrays use .length, ArrayLists use .size().
ArrayList (Unit 7)
ArrayLists are where this exception bites hardest because their size changes. Calling remove mid-loop shrinks the list, so a loop bound you checked at the start can become invalid by the end. A fixed-size array never moves the goalposts on you like that.
Indexed for loop (Units 6-7)
The indexed for loop is where the off-by-one error lives. The condition i < list.size() is safe; i <= list.size() guarantees a crash on the final iteration because get(size()) is one past the last element.
Exception (Unit 1)
IndexOutOfBoundsException is one of a handful of runtime exceptions AP CSA expects you to recognize by name, alongside NullPointerException and ArithmeticException. Knowing which error a code snippet produces is a recurring MCQ format.
On the multiple-choice section, this term shows up two ways. First, direct recall, like "what exception is thrown when you access an invalid index in an ArrayList?" or "what happens if you access index 10 in an ArrayList of size 8?" The answer is that an IndexOutOfBoundsException is thrown at runtime. Second, and more often, it's hidden inside code-tracing questions. You'll see a loop with a condition like i <= list.size(), or a method that removes elements while traversing, and you have to recognize the code will crash (or skip elements) instead of producing one of the tempting normal-output answer choices. No released FRQ asks you to name the exception, but FRQ scoring penalizes loop bounds that go out of range, so writing i < list.size() correctly is worth real points on array and ArrayList free-response questions.
Same mistake, different structure. An invalid index on a plain array (like arr[arr.length]) throws ArrayIndexOutOfBoundsException, while an invalid index on an ArrayList (like list.get(list.size())) throws IndexOutOfBoundsException. Technically the array version is a subclass of the list version, but on the exam the cue is the data structure in the code. Square brackets point to the array exception, get/set/remove point to the ArrayList one.
An IndexOutOfBoundsException happens at runtime, not compile time, when you access an index outside an ArrayList's valid range of 0 to size() - 1.
Calling get(10) on an ArrayList of size 8 throws this exception because the last valid index is 7.
The loop condition i < list.size() is safe, but i <= list.size() always crashes on the last iteration.
Removing elements during an indexed loop shrinks the list, which can push your index past the new size and trigger this exception.
Plain arrays throw the more specific ArrayIndexOutOfBoundsException, while ArrayList methods throw IndexOutOfBoundsException.
Modifying an ArrayList inside an enhanced for loop throws a different error, ConcurrentModificationException, not an IndexOutOfBoundsException.
It's a runtime exception thrown when code accesses an invalid index in an ArrayList, like calling get(8) on a list of size 8. Valid indices always run from 0 to size() - 1.
No. The code compiles perfectly fine and only crashes when it runs and actually hits the bad index. That's why MCQ answer choices like "compile-time error" are usually wrong for indexing mistakes.
ArrayIndexOutOfBoundsException comes from plain arrays (accessing arr[arr.length] or beyond), while IndexOutOfBoundsException comes from ArrayList methods like get and remove. On the exam, match the exception to the data structure in the code.
The program throws an IndexOutOfBoundsException at runtime, because the highest valid index in a size-8 list is 7. Nothing is returned and the program stops unless the exception is handled.
In an indexed for loop, removal usually causes skipped elements rather than a crash, but it can throw this exception if your loop bound was computed before the list shrank. In an enhanced for loop, removal throws a ConcurrentModificationException instead.