You catch an error inside an async JavaScript function so you can log it, but the caller still needs to know the operation failed. What are your options for passing the failure on, and what does each do to the promise that async function returns?

## What a catch clause does to the returned promise An async function's promise settles from how the body finishes. Normal completion or `return v` fulfils it with `v`; an uncaught exception rejects it. A `catch` clause is a normal completion path — so once you catch, the error is *gone* unless you deliberately re-signal it: ```js async function loadConfig() { try { return await readFile('config.json'); } catch (err) { logger.error('config read failed', err); // logged... } // ...and swallowed } ``` `loadConfig()` fulfils with `undefined`. The caller's `await` succeeds, and the `undefined` propagates into code that expected a config object, usually producing a `TypeError` several frames away from the real cause. This is the single most consequential decision in the block: consume or propagate. ## The three ways to propagate **Rethrow the original.** ```js catch (err) { logger.error('config read failed', err); throw err; } ``` The returned promise rejects with the exact same value. Type is preserved, so a caller's `err instanceof FileNotFoundError` or `err.code === 'ENOENT'` still works, and the stack still points at where the error was constructed. Use this when this layer adds no information the caller lacks. **Wrap with a cause.** ```js catch (err) { throw new Error(`loading ${path} failed`, { cause: err }); } ``` The `{ cause }` options bag is ES2022 and sets the new error's `cause` property to the original, so nothing is lost: the caller reads `err.message` for this layer's context and `err.cause` for the underlying failure. Modern runtimes print the cause chain when logging the outer error. The tradeoff is that the outer error is a plain `Error` — callers that were branching on the inner type now have to look at `err.cause`, so wrapping is a contract change at that boundary, not a free improvement. **Return a rejected promise.** ```js catch (err) { return Promise.reject(err); } ``` Identical outcome to `throw err` in an async function, occasionally handier inside an expression. `throw` reads better and is the convention. ## Choosing between them The useful heuristic is *does this layer know something the caller does not*. A repository function that knows the query, the table, and the parameters can turn `ECONNRESET` into `"loadUser(42) failed"` with the original as the cause — real added context. A pass-through helper that just forwards a call knows nothing extra; wrapping there adds a message that says the same thing twice and buries the real error one level deeper. Every wrap layer costs one `.cause` hop for whoever reads the log. The related anti-pattern is log-and-rethrow at every level. Each layer logs the same failure, so one incident produces five stack traces with the same root and no additional facts. Pick one place — usually the outermost boundary that has request context — to log, and let the intermediate layers either wrap silently or not catch at all. ## Conditional rethrow JavaScript has no typed catch clauses, so selective handling is a branch inside the block, and the `else` branch must rethrow: ```js catch (err) { if (err instanceof NotFoundError) return null; // handled: legitimate absence throw err; // everything else propagates } ``` Forgetting the trailing `throw err` is how a broad `catch (err) { return null; }` turns a database outage into an empty result set. The same applies to `catch` blocks that inspect `err.code`: unrecognised codes must escape. ## Rethrowing from a finally-adjacent position If cleanup lives in a `finally` next to this `catch`, remember that a throw from the `finally` block replaces whatever the `catch` rethrew. Best-effort teardown belongs in its own try/catch so the error you deliberately propagated is the one that survives. ## What the caller sees Whichever option you choose, the caller's experience is uniform: their `await` throws, their `try`/`catch` runs, their `.catch` fires. That uniformity is the point — an async function has exactly one failure channel, its returned promise, and the only question the catch clause answers is whether a failure is put back into it. ## Non-Error values If the caught value is not an `Error` — a string, a rejected response object — wrapping is also the moment to normalise it: `throw new Error('upstream failed', { cause: err })` gives downstream handlers a real stack and message regardless of what the library rejected with. Rethrowing verbatim preserves the oddity for everyone above you.