In a promise chain, what is the difference between handling errors with the second argument of .then(onFulfilled, onRejected) and appending a separate .catch()?

## They are the same primitive `Promise.prototype.catch(fn)` is defined as calling `this.then(undefined, fn)`. There is no extra machinery. So the question is never "which method handles errors better" — it is "where in the chain does the rejection handler sit?" ## Two handlers on the same link vs. one on the next link Consider the two shapes: ```js p.then(onFulfilled, onRejected); // A: alternatives for the same promise p.then(onFulfilled).catch(onRejected); // B: handler on the derived promise ``` In shape **A**, `p` settles once, and its outcome selects exactly one of the two callbacks. If `p` fulfills, `onFulfilled` runs and `onRejected` is discarded — permanently, including if `onFulfilled` itself throws. That throw rejects the promise returned by `.then`, and the rejection travels *downstream* looking for a handler; `onRejected` is not downstream, it is a sibling. In shape **B**, `.then(onFulfilled)` produces a new promise, and `.catch(onRejected)` handles *that* one. It therefore sees two kinds of failure: a rejection of `p` passed through the fulfillment-only `.then`, and a rejection produced by `onFulfilled` throwing. ```js Promise.resolve('ok') .then( () => { throw new Error('render failed'); }, () => console.log('A: not called'), ) .catch((err) => console.log('B: caught', err.message)); // B: caught render failed ``` ## Why the difference is useful, not just a trap The two-argument form gives you something `.catch` cannot: **scoped** error handling. Its handler covers exactly the upstream step and nothing else. That is what you want when a specific step has a specific recovery, and you do not want that recovery to accidentally absorb unrelated bugs in the code that consumes the result: ```js loadSettings() .then( (settings) => applySettings(settings), () => applySettings(DEFAULTS), // only a load failure lands here ) .catch(reportCrash); // applySettings bugs land here ``` A single trailing `.catch` cannot express that: it cannot tell whether the failure came from `loadSettings` or from `applySettings`. The two-argument form draws the boundary structurally. The mirror-image trap is real too. A `.catch` placed *before* the rest of the chain only guards what precedes it: ```js fetchUser() .catch(() => null) // guards fetchUser only .then((u) => u.name); // TypeError here is NOT handled ``` So "use `.catch`" is shorthand for "put the rejection handler after everything you want it to cover", not for a different feature. ## Pass-through rules that make it work Two spec details explain the routing: - If the fulfillment handler is missing or not a function, a fulfilled value passes through unchanged. That is what lets `.catch` sit in the middle of a chain of successful steps without disturbing them. - If the rejection handler is missing or not a function, a rejection passes through unchanged. That is what lets a rejection skip every plain `.then(fn)` on its way to the nearest handler. Because `.catch` supplies only the second handler, it is transparent to success and opaque to failure — which is exactly the behaviour you want at the end of a pipeline. ## Practical guidance - Default to a trailing `.catch` for the whole chain; it is the shape most readers expect, and it covers every step. - Reach for `.then(onFulfilled, onRejected)` only when the narrower scope is the point — a per-step fallback whose recovery must not mask errors in the success path. - Never write `.then(onFulfilled, onRejected)` believing it is a defensive wrapper around `onFulfilled`. It is the one thing it is not. - Both forms can appear in one chain: a scoped two-argument handler for a known recoverable step, plus a trailing `.catch` as the backstop for everything else. ## What to say in an interview "`.catch(fn)` *is* `.then(undefined, fn)`, so the only difference is where the handler sits. The second argument of `.then` is an alternative to its own success callback and can never catch that callback's throw; a trailing `.catch` sits one link downstream and catches both. I use the two-argument form when I deliberately want a per-step recovery that does not swallow bugs in the consumer."