Inside an `Array.prototype.forEach` callback, what do `return` and `break` actually do, and how do you stop iterating early?

## forEach is a method call, not a loop The confusion starts with the shape of the code: `arr.forEach((x) => { ... })` looks like a loop body in braces, so people reach for loop keywords. But `forEach` is an ordinary method. Roughly, it does this: ```js // conceptually for (let k = 0; k < len; k++) { if (k in arr) callback(arr[k], k, arr); } ``` The braces you wrote belong to a *function*, and that function is called once per element. Everything that follows falls out of that fact. ## return: acts like continue, and the value is thrown away `return` ends the current invocation of your callback and control goes straight back to `forEach`, which moves on to the next index. Net effect: it behaves exactly like `continue` in a real loop. ```js [1, 2, 3, 4].forEach((n) => { if (n === 3) return; // skips 3 only console.log(n); // 1, 2, 4 }); ``` Also important: `forEach` **discards** whatever the callback returns. `return false` does not stop it — a habit carried over from libraries like older jQuery's `$.each`, where returning `false` did break the loop. In plain JavaScript it does nothing. And `forEach` itself always returns `undefined`, so it cannot be chained. ## break: a SyntaxError, not a runtime surprise ```js [1, 2, 3].forEach((n) => { if (n === 2) break; // SyntaxError: Illegal break statement }); ``` This fails before a single element is visited, because `break` is only valid inside an iteration statement or `switch`, and a function body resets that context. The same applies to `continue`. That the failure is a parse error rather than a runtime one is a good detail to mention — it shows you know the callback is a real function boundary, not a block. ## The escape hatches, from worst to best **Throwing.** You can throw a sentinel and catch it outside. It works because the exception propagates out of the callback, through `forEach`, to your `try`. It is also unreadable, expensive relative to a loop, and hijacks a mechanism meant for errors. Do not do this to control iteration. **Mutating the array.** Setting `arr.length = 0` or splicing mid-flight makes `forEach` stop finding elements. This is a trap, not a technique: it destroys the data you were iterating and interacts badly with the fact that `forEach` caches the length before it starts. **Picking the right construct.** This is the actual answer: - `for...of` — full loop semantics. `break`, `continue`, and `return` out of the enclosing function all work, and `await` works too because there is no callback boundary. - `some(predicate)` — stops as soon as the predicate returns truthy and yields `true`. The idiomatic "loop until found" when you only need a yes/no. - `every(predicate)` — stops as soon as the predicate returns falsy. The mirror image; also the idiomatic "check all" that short-circuits. - `find` / `findIndex` — stop at the first match and hand you the element or index. - A classic `for (let i = 0; ...)` — when you need to control the index, iterate backwards, or skip in steps. ```js const users = [{ id: 1 }, { id: 2 }, { id: 3 }]; // stops at the match, no wasted work const target = users.find((u) => u.id === 2); // stops at the first failure const allValid = users.every((u) => typeof u.id === 'number'); // full control flow for (const u of users) { if (u.id === 2) break; } ``` ## Why `some` reads badly when abused A pattern you will see is `arr.some((x) => { doWork(x); return shouldStop(x); })` — using `some` purely as a breakable `forEach` and ignoring its boolean result. It works, but the method name lies about the intent, and the next reader has to stop and decode it. `for...of` with `break` says the same thing in plain language, and it is not slower in any way that matters. ## When forEach is still the right call None of this makes `forEach` bad. When you genuinely want a side effect applied to every element, with no early exit and no `await` in sight, `forEach` is concise and signals "all of them, unconditionally" to the reader. The rule is simply: the moment you need to stop early, `forEach` is the wrong tool, and reaching for `throw` to force it is a design smell rather than a clever trick.