When a .catch() handler on a promise chain returns a value normally instead of rethrowing, what state is the promise it returns in, and how does the rest of the chain behave?

## Handlers decide the next state A rejection handler is just a callback whose completion decides the state of the promise `.catch()` returned: - **returns a value** → that promise **fulfills** with the value; - **returns a promise/thenable** → it adopts that promise's eventual state (so returning a rejected one keeps the chain failed); - **throws** → that promise **rejects** with the thrown value. There is no fourth option meaning "stay broken but do not throw". Falling off the end of a handler returns `undefined`, which is a *value*, so the chain is fulfilled with `undefined`. ## Recovery: the intended use ```js loadRecommendations() .catch(() => []) // recover with an empty list .then((items) => render(items.length)); // runs with [] on failure ``` This is the promise equivalent of a `catch` block that supplies a default. The important property is that the recovery value must be *shape-compatible* with what the success path produced — here an array, so `items.length` is safe either way. A recovery that returns something the next step cannot use has not recovered anything; it has moved the crash. ## The swallowing bug The same rule produces the most common promise bug in real code: ```js fetchUser(id) .catch((err) => console.error(err)) // returns undefined! .then((user) => user.profile.name); // TypeError: user is undefined ``` The author's intent was "log it and stop". What they wrote was "log it, then continue with `undefined`". The resulting `TypeError` points at the property access, not at the failed fetch, so the stack trace blames the wrong line — and if that second failure is also swallowed somewhere, a request quietly returns garbage instead of an error. Worse, a `.catch` at the *end* of a function whose result is returned to a caller reports success upward: ```js function getUser(id) { return fetchUser(id).catch((err) => logger.warn(err)); // resolves undefined } ``` Every caller now believes `getUser` succeeded. ## Staying failed: rethrow or return a rejection ```js .catch((err) => { metrics.increment('user.fetch.failed'); throw err; // same reason continues downstream }) ``` Rethrowing the *same* error keeps the original reason and its stack intact, which is what you want for a pure observe-and-continue handler. Throwing a *new* error is a deliberate translation — turning a low-level failure into a domain-level one at a boundary — and it replaces the reason, so preserve what you need from the original when you do it. Returning `Promise.reject(err)` is equivalent to rethrowing for propagation purposes; `throw` is the more direct expression and is preferred in a synchronous handler body. ## Where this bites hardest With `async`/`await` the same rule applies but reads differently, because falling off the end of a `catch` block also produces a normally-returning function. The promise vocabulary just makes it visible: a rejection handler is a *transformation* of the failure into some next state, and the default transformation — returning `undefined` — is almost never what you meant. A useful review heuristic: **every rejection handler must end in one of three ways** — a real fallback value, a rethrow, or being the genuine end of the chain where nothing downstream consumes the result (a top-level entry point that only reports). A handler that logs and is followed by more chain is a defect. ## Ordering note Only the *first* rejection handler downstream sees the error. Once it returns normally, the chain is fulfilled, and any further `.catch` later in the same chain is skipped entirely — it will only fire if a *later* step fails. Multiple `.catch` calls in one chain therefore do not mean "multiple chances to handle the same error"; they mean "different guards for different segments". ## What to say in an interview "Returning from `.catch` fulfills the promise it returned, so the chain resumes on the success path with that value — that is how you supply a fallback. A handler that only logs returns `undefined`, so the next step gets `undefined` and usually throws a `TypeError` far from the real cause. If the chain should stay failed, rethrow the error or return a rejected promise."