Why is catching ArrayIndexOutOfBoundsException usually a code smell, and what should you do instead?

## Checked vs. unchecked, and what AIOOBE signals Java exceptions split into **checked** (must be declared/caught; represent recoverable, expected conditions like a missing file) and **unchecked** (`RuntimeException` and subclasses; the compiler doesn't force handling). `ArrayIndexOutOfBoundsException` is **unchecked**. The deliberate design message is: *this represents a bug in the program's logic, not an external condition you should routinely recover from.* An index went out of range because some assumption in your code was wrong. ## Why catching it is usually wrong 1. **It hides bugs.** If your loop has an off-by-one error, the right outcome is to *find and fix it*. Wrapping the access in `try/catch` and ignoring (or 'handling') the exception masks the defect and can leave data half-processed. 2. **It's a blunt instrument.** A `catch (AIOOBE e)` may also swallow an out-of-bounds access from a *different* line you didn't anticipate, turning a clear crash into silent wrong behavior. 3. **It's slow and abused as control flow.** Building and throwing an exception (capturing a stack trace) is far more expensive than an `if`. Using exceptions for ordinary branching is an anti-pattern. 4. **It obscures intent.** A reader sees a `catch` and assumes the condition is expected/recoverable, which it usually isn't. ## What to do instead — prevent, don't catch **Write correct loops.** Use the half-open convention so the index can't escape: ```java for (int i = 0; i < a.length; i++) { ... } // never reaches a.length ``` For-each (`for (int x : a)`) removes index management entirely and can't go out of bounds. **Validate at trust boundaries.** When an index comes from outside (user input, a network message, another module), check it *before* use and fail with a precise error: ```java int i = request.getIndex(); if (i < 0 || i >= a.length) { throw new IllegalArgumentException("index " + i + " out of range 0.." + (a.length - 1)); } use(a[i]); ``` The JDK provides helpers: **`Objects.checkIndex(i, length)`** returns `i` if valid and throws `IndexOutOfBoundsException` otherwise, giving you a one-liner guard at the boundary. There's also `checkFromIndexSize` for ranges. **Clamp when a value is genuinely 'best effort'.** If the contract is 'use the nearest valid element', clamp explicitly: `i = Math.max(0, Math.min(i, a.length - 1));` — this is a *deliberate* decision, not exception-swallowing. ## The rare legitimate catch At a hard outer boundary (e.g. a request handler that must never crash the server), a broad `catch` may convert any unexpected failure into a 500 response. That's catching *all* unexpected exceptions for resilience, not specifically using AIOOBE for control flow — and you should still **log it as a bug** so it gets fixed. ## Mental model Bounds checking is a **safety net that surfaces programmer mistakes early**. The goal is for AIOOBE to fire **during development/testing** (where it points you straight at the bug) and to **never fire in production** because your loops are correct and your inputs are validated. ## Key takeaways - AIOOBE is unchecked → it signals a logic bug, not a recoverable condition. - Catching it hides bugs, can swallow unrelated errors, and is slow as control flow. - Prevent it: half-open loops, for-each, and validating/clamping external indices (e.g. `Objects.checkIndex`). - A broad outer catch for resilience is different — and should still log the bug.