ArrayIndexOutOfBoundsException is a runtime exception Java throws when code tries to access an array index that doesn't exist, meaning the index is negative or greater than or equal to the array's length. In AP CSA, valid indices always run from 0 to array.length - 1.
ArrayIndexOutOfBoundsException is Java's way of telling you that your code asked an array for a spot that isn't there. Every array in Java has a fixed length, and its valid indices run from 0 up to length - 1. The moment your code uses an index that's negative or that's length or bigger, the program stops and throws this exception at runtime. It compiles fine. The compiler can't see the problem because the index is usually computed while the program runs.
The classic trigger is an off-by-one error in a loop. If values has 8 elements, then values[8] doesn't exist, so a loop condition like i <= values.length walks one step too far and crashes on the last iteration. Think of an array like a row of 8 numbered lockers, labeled 0 through 7. Asking for locker 8 doesn't give you an empty locker. Java just refuses and throws the exception.
This exception lives at the heart of the array units in AP CSA (arrays in Unit 6, ArrayList in Unit 7, and 2D arrays in Unit 8). The CED expects you to know that accessing an index outside the valid range causes an ArrayIndexOutOfBoundsException to be thrown, even though you're never asked to write try/catch code on the exam. In other words, AP CSA tests your ability to recognize and predict this error, not handle it. That makes it a favorite trap in multiple-choice questions about loop bounds, and it's a top reason FRQ array-traversal answers lose points. Knowing exactly where the valid index range ends (length - 1) is the skill being checked.
Keep studying AP Computer Science A Unit 4
array.length (Unit 6)
The exception and length are two sides of the same rule. array.length tells you how many elements exist, but the last valid index is length - 1. Almost every ArrayIndexOutOfBoundsException on the exam comes from forgetting that one-off gap.
Bounds checking (Unit 6)
Bounds checking is the habit that prevents this exception. Writing loop conditions like i < arr.length instead of i <= arr.length is the single most common bounds fix AP CSA questions ask you to spot.
Exception handling and the remove method (Unit 7)
ArrayList methods like get, set, and remove(int index) throw an IndexOutOfBoundsException when given a bad index. Same idea as the array version, just thrown by ArrayList. Practice questions ask exactly what happens when remove gets an out-of-bounds index, and the answer is an exception, not a silent failure.
Runtime error vs. compile-time error (Unit 1)
This exception is the textbook example of a runtime error. The code is legal Java and compiles cleanly, but it crashes while running. MCQs love asking you to classify an error, and 'compiles but throws an exception' is a frequent correct answer.
You'll see this almost entirely in multiple-choice questions that show you a code segment and ask what happens when it runs. The pattern to hunt for is a loop whose index can reach arr.length, like for (int i = 1; i <= values.length; i++) or for (int i = 0; i <= nums.length; i++). Both look reasonable at a glance, and both crash with ArrayIndexOutOfBoundsException on the final iteration. Questions also test ArrayList versions, such as what happens when remove(int index) is called with an out-of-bounds index. On FRQs, you won't write try/catch (exception handling isn't part of the AP CSA subset), but writing a traversal loop with bad bounds in your array or 2D array FRQ answer will cost you points. Your job on the exam is to predict the exception, identify the exact line or iteration where it happens, and write loop bounds that never let it happen.
Both are runtime exceptions you must recognize for AP CSA, but they mean different things. ArrayIndexOutOfBoundsException means the array exists but you asked for an index outside 0 to length - 1. NullPointerException means the array (or object) reference is null, so there's no array there at all. Quick test: bad index on a real array means out of bounds; calling anything on a null reference means null pointer.
ArrayIndexOutOfBoundsException is thrown at runtime when an array index is negative or greater than or equal to the array's length.
Valid indices for any Java array run from 0 to array.length - 1, so arr[arr.length] always throws the exception.
Loop conditions using <= arr.length are the most common cause, and the crash happens on the last iteration, not the first.
The code compiles without errors; this is a runtime error, which is exactly how MCQs like to disguise it.
ArrayList methods like get, set, and remove throw the closely related IndexOutOfBoundsException for invalid indices.
AP CSA never asks you to write try/catch for this; you only need to recognize when and why the exception is thrown.
It's a runtime exception Java throws when code accesses an array index that's negative or greater than or equal to the array's length. For an array of length 8, only indices 0 through 7 are valid, so arr[8] throws the exception.
No. Exception handling with try/catch is outside the AP CSA Java subset. You only need to recognize when this exception is thrown and predict where code will crash.
No, it's strictly a runtime error. Code like values[values.length] = 5 compiles perfectly fine and only crashes when the program actually runs that line, which is why MCQs use it as a trap.
ArrayIndexOutOfBoundsException means the array exists but the index is invalid. NullPointerException means the reference is null, so there's no array to index into at all. Check whether the array was ever created, then check the index range.
Java throws an IndexOutOfBoundsException, the ArrayList cousin of the array version. The call doesn't silently fail or return null. The program stops at that line, and AP practice questions test exactly this.