What does calling `gen.throw(new Error('boom'))` do to a paused JavaScript generator, and what happens if the generator has not started running yet?

## Three ways to resume A suspended generator can be resumed with three different completions. `next(v)` delivers a normal value, so the paused `yield` evaluates to `v`. `return(v)` delivers a return completion, so the paused `yield` behaves like a `return v`. `throw(err)` delivers a throw completion: the paused `yield` expression **throws** `err` inside the generator body, at exactly the point where it was suspended. That symmetry is the mental model to carry into the interview: `yield` is a two-way door, and errors travel through it inward just as values do. ## Catching it inside the body ```javascript function* worker() { while (true) { try { const task = yield 'ready'; console.log('did', task); } catch (err) { console.log('recovered from', err.message); } } } const g = worker(); g.next(); // { value: 'ready', done: false } console.log(g.throw(new Error('boom')).value); // logs 'recovered from boom', then 'ready' ``` The generator was paused at `yield 'ready'` inside a `try`. `throw()` makes that expression throw; the `catch` handles it; the `while` loop goes round again and hits `yield 'ready'` a second time. Because the generator suspended again rather than finishing, `throw()` returns a perfectly ordinary `{ value: 'ready', done: false }` result. From the caller's point of view, `throw()` behaved like `next()` that happened to deliver bad news. ## When nothing catches it If the body has no handler for the error, it unwinds. Enclosing `finally` blocks still run — this is ordinary exception propagation inside the generator's own context — the generator is marked completed, and the error is rethrown out of the `gen.throw(...)` call itself. So the caller must be prepared for `throw()` to throw: ```javascript function* plain() { yield 1; yield 2; } const g = plain(); g.next(); try { g.throw(new Error('boom')); // rethrown here — nothing in the body catches } catch (err) { console.log('caller saw', err.message); // 'caller saw boom' } console.log(g.next()); // { value: undefined, done: true } ``` Notice the generator is finished afterwards. An uncaught injected error is a completion, not a hiccup. ## The not-yet-started case The case people get wrong is a generator that has never been advanced. It is suspended *before* the first statement, which means it has entered no `try` block — there is literally no handler in scope, because none of the body has executed. ```javascript function* g2() { try { yield 1; } catch (e) { console.log('caught'); // never logs in this scenario } } const g = g2(); try { g.throw(new Error('early')); } catch (e) { console.log('propagated', e.message); // 'propagated early' } ``` No body code runs, `'caught'` is never logged, the generator becomes completed, and the error goes straight back to the caller. The same holds for a generator that has already completed: `throw()` on it rethrows to the caller rather than doing anything internally. Compare this with `return()` on an unstarted generator, which quietly completes it with `{ value, done: true }` instead of throwing. ## What it is actually for Most application code never calls `throw()`. Its real users are drivers — code that pulls values from a generator, does something fallible with each one, and wants the failure reported *at the point in the generator that produced it* so the generator can decide whether to retry, skip, or give up. Because the body sees a normal exception at the `yield`, it can express that policy in plain `try`/`catch`, which is far more readable than threading error objects through `next()` and checking them by hand. This same shape — deliver a rejection into the body so `try`/`catch` around the suspension point handles it — is what makes coroutine-style error handling work in general. ## Interview traps The things that separate answers: knowing that a caught injection produces an ordinary `done: false` result rather than ending the generator; knowing that an uncaught one both completes the generator and rethrows to the caller; knowing that `finally` still runs during that unwinding; and knowing the unstarted generator ignores its own `catch` because it never entered the `try`.