An async generator throws — or awaits a promise that rejects — after having already yielded two values. Where does that error surface for the consumer, and can the generator still produce values afterwards?

## Where the error goes An async generator produces one result per resumption, and the vehicle for each result is the promise that `next()` returned. A successful resumption fulfils that promise with `{ value, done }`. A resumption whose body throws **rejects** it with the thrown value. Nothing else changes: the two values already yielded were already delivered and are unaffected. ```js async function* g() { yield 1; yield 2; throw new Error("boom"); } const it = g(); await it.next(); // { value: 1, done: false } await it.next(); // { value: 2, done: false } await it.next(); // rejects with Error: boom ``` Because `for await...of` awaits each `next()`, a rejection surfaces as a throw *at the loop statement*, at the position where that item would have appeared: ```js try { for await (const n of g()) console.log(n); // 1, 2 } catch (e) { console.log("caught", e.message); // caught boom } ``` A rejected `await` inside the body behaves identically — in an async function body, an unhandled rejection *is* a throw, so `await failingCall()` and `throw new Error()` reach the consumer by the same path. ## Cleanup still runs The throw unwinds the body, so enclosing `finally` blocks execute before the rejection is delivered to the consumer. That ordering matters: by the time the consumer's `catch` runs, the generator has already released whatever its `finally` released. If the `finally` itself throws, its exception replaces the original one, which can hide the real cause — a good reason to catch and log inside cleanup rather than let a failing `close()` propagate. ## Completion is permanent Once an error escapes the body, the generator's state becomes *completed*, exactly as if it had returned. That state is terminal: ```js await it.next(); // rejects with boom await it.next(); // { value: undefined, done: true } — no rethrow ``` The error is delivered **once**, to whoever was pulling at that moment. A second consumer, or the same consumer retrying, sees a quietly exhausted iterator rather than the failure. This surprises people who expect a "poisoned" iterator to keep reporting its error. If the failure must be observable more than once, the caller has to record it — the generator will not repeat itself. The same terminality applies after a normal `return` and after `return()` was used to terminate early: once completed, `next()` always fulfils with `{ value: undefined, done: true }`. ## Errors travelling the other way: throw() The async iterator protocol also lets the *consumer* push an error into the producer. `it.throw(err)` resumes the suspended body with a throw completion at the `yield` point, so the generator's own `try`/`catch` can handle it: ```js async function* resilient() { while (true) { try { yield await fetchNext(); } catch (e) { // consumer-injected or fetch failure: log and keep going } } } ``` If the body catches it, the generator continues and `throw()`'s promise fulfils with whatever it yields next. If the body does not catch it, the error propagates out of `throw()`'s promise and the generator completes. This is the mechanism behind "tell the producer that downstream failed" designs, and it is why a body that wraps its yields in `try`/`catch` can be made resilient to consumer-side failures. ## Partial consumption is the real design question The practical consequence of positional error delivery is that a consumer can be left half-way through a sequence with work already committed. Two values were processed; the third failed. Unlike a promise of a whole array, which fails atomically, streaming makes partial progress the normal case, so the consumer needs a policy: discard the partial work, checkpoint how far it got and resume from there, or treat each item as independently committed. Deciding this is part of choosing a streaming producer in the first place — it is not something the generator can decide for you. One more trap: if you create a generator, pull from it, and drop it after a rejection without observing that rejection — for example by starting a `next()` you never await — you get an unhandled rejection report. Every `next()` promise you create is a promise someone must handle.