A `for...of` loop over a JavaScript generator hits `break` before the generator is exhausted. What does the language do to the suspended generator, and how do you guarantee its cleanup runs?

## Early exit is not abandonment A suspended generator is not a thread and does not keep running, but it is also not garbage the moment a consumer stops reading. It holds live state: whatever the body opened before the current `yield` is still open. If that body opened a file handle, took a lock, or started a transaction, silently walking away would leak it. The language handles this with a defined **close** step. When a `for...of` loop leaves early, the specification runs `IteratorClose` on the iterator: it looks up a `return` method on the iterator and, if one exists, calls it. Generators have one, so this is not something you opt into. ```javascript function* lines() { try { yield 'a'; yield 'b'; yield 'c'; } finally { console.log('closing'); } } for (const line of lines()) { if (line === 'b') break; // logs 'closing' before leaving the loop } ``` The `finally` block runs at the moment of the `break`, before the statement after the loop. ## What `return()` actually does `gen.return(v)` resumes the generator with a *return completion* rather than a value. Semantically it behaves as though a `return v` statement had been inserted at the point where the generator is paused. That means: - every `finally` block whose `try` the generator has entered runs, innermost first; - no more `yield`s in the normal path are reached; - the call returns `{ value: v, done: true }`, and the generator is completed; - subsequent `next()` calls return `{ value: undefined, done: true }`. Called by hand it looks like this: ```javascript const g = lines(); g.next(); // { value: 'a', done: false } console.log(g.return(0)); // logs 'closing', then { value: 0, done: true } console.log(g.next()); // { value: undefined, done: true } ``` Two edge cases are worth knowing. First, a generator that has never been started has entered no `try` block, so `return()` completes it without executing a single line of the body — if your cleanup assumption is "the finally always runs", it does not run when nothing was ever set up, which is the correct behaviour but surprises people. Second, if a `finally` block itself contains a `yield`, the generator suspends again inside the cleanup and `return()` reports `done: false`; the close is not finished until the consumer drives it through. That is an easy way to write a generator that resists closing, and a good reason to keep `finally` blocks yield-free. ## Which consumers close and which do not The close step fires for early exit from `for...of`, and also for destructuring that stops short — `const [first] = lines()` takes one element and then closes the generator, running the `finally`. Consumers that run to exhaustion (spread, `Array.from`, a `for...of` that completes normally) never need the close step: the generator finishes on its own, and its `finally` runs as part of ordinary completion. What does **not** happen automatically is cleanup for a generator you drive manually with `next()` and then simply stop using. There is no destructor hook; garbage collection does not resume a generator to run its `finally`. If you hand-drive a generator that owns a resource, you must call `return()` yourself, typically in your own `finally`: ```javascript const g = lines(); try { const first = g.next().value; // …work with first, maybe throw… } finally { g.return(); // idempotent: safe even if g is already done } ``` `return()` on an already-completed generator is harmless — it just reports `{ value, done: true }` — so this pattern is safe to apply unconditionally. ## The design rule The practical takeaway is a placement rule. Anything a generator must undo goes in a `finally` that wraps the yields; anything written after the last `yield` is best-effort only, because a consumer is free to stop at any point. Interviewers like this question because it is the moment a candidate stops treating a generator as "a lazy array" and starts treating it as a resource with a lifecycle — created, driven, and closed — where the consumer, not the producer, decides when the sequence ends. ## Diagnosing it When a service leaks handles under load and the code path involves iteration, the tell is a generator whose cleanup sits after its final `yield` while callers routinely `break` on a match or a limit. The fix is small — move the cleanup into `finally` — but you only find it if you know that leaving a loop early stops the body permanently rather than letting it fall through to the end.