Output Quiz #7 — Promise Chaining & the .catch() Recovery Rules

Output:

1
11

Why: When a .then() callback returns a plain value, that value is automatically wrapped in a resolved Promise for the next handler. v + 10 is 11, so the second .then() receives 11.

Output:

start
catch: oops

Why: When .then() returns a rejected Promise, the chain switches to the rejected track. The next .then() is skipped entirely, and the nearest .catch() fires. Returning Promise.reject(x) from inside .then() is equivalent to throwing x.

Output:

caught: error
then: recovered

Why: .catch() that returns a plain value converts the chain back to the resolved track. The .then() after .catch() runs normally and receives the returned value. Think of .catch() as a checkpoint: handle the error, return something, and the chain continues as if nothing went wrong.

Output:

first catch: first error
second catch: second error

Why: If .catch() throws (or returns Promise.reject()), the chain stays on the rejected track. The error propagates to the next .catch(). This is how error re-throwing works — you can inspect the error and decide to re-throw it or swallow it.

Output:

finally
then: 42

Why: .finally() receives no arguments — it does not see the resolved value. Its return value is also ignored (unless it throws). The original value 42 passes through unchanged to the next .then(). This makes .finally() ideal for cleanup like hiding a spinner — you don't need the value, and you don't want to interfere with it.

Output:

catch: finally error

Why: If .finally() throws (or returns a rejected Promise), the original resolved value is discarded and the chain switches to rejected. The .then() is skipped and .catch() fires with the error from .finally(). This is the one case where .finally() changes the outcome of the chain.

Output:

catch: thrown in onFulfilled

Why: The onRejected in .then(onFulfilled, onRejected) handles rejections from the preceding promise — not errors thrown by onFulfilled in the same call. When onFulfilled throws, the error escapes past onRejected and is caught by the next .catch() in the chain. This is why .then(fn).catch(err) is usually preferred over .then(fn, err) — the standalone .catch() also covers errors from fn.

Output:

1
3
2
4

Why: Both chains start with already-resolved Promises, so both first .then() callbacks are queued as microtasks immediately. The microtask queue at the end of sync: [cb1, cb3].

• cb1 runs → logs 1 → schedules cb2. Queue: [cb3, cb2]
• cb3 runs → logs 3 → schedules cb4. Queue: [cb2, cb4]
• cb2 runs → logs 2. Queue: [cb4]
• cb4 runs → logs 4.

The chains interleave breadth-first, not depth-first. Many developers expect 1 2 3 4 — this is one of the most commonly wrong answers in senior JS interviews.

Output:

inner: inner
outer: inner

Why: When resolve is called with another Promise (inner), the engine cannot resolve outer directly — it must first call inner.then(resolveOuter, rejectOuter) to "adopt" the inner Promise's state. That adoption is itself a microtask.

Timeline:

1. Sync ends. Microtask queue: [adopt inner→outer, inner.then(log "inner")]
2. Adoption runs → outer resolves → queues outer.then(log "outer")
3. Queue: [inner.then(log "inner"), outer.then(log "outer")]
4. inner: inner logs, then outer: inner logs.

If you had used resolve("inner") (a plain value) instead, outer would resolve in the same microtask tick as inner, and the order would be determined by registration order. The extra adoption step is the critical difference.

Output:

true
false

Why: Promise.resolve(x) has a fast path: if x is already a native Promise from the same realm, it returns x unchanged — no new object is created, no wrapping. p === p2 is true.

new Promise(resolve => resolve(p)) always creates a new Promise object. Even though it eventually resolves to the same value as p, it is a different object. p === p3 is false. This also means p3 has the extra adoption tick from Q9 — p would resolve first.