Inside a JavaScript catch block you decide the failure is not yours to handle. Compare `throw err;`, `throw new Error(err.message);`, and logging the error and returning — what does each leave the outer caller with?

## Three things a catch block can do, and what each costs Once you have caught something, you own the decision about what the outer caller learns. There are only three real options — rethrow as-is, rethrow something new, or stop the propagation — and they differ enormously in how much context survives. ### 1. `throw err;` — lossless rethrow A bare rethrow of the caught binding throws the **same object**. Object identity is preserved, which means: - `err.name` and any subclass identity survive, so outer `instanceof` checks still work; - custom properties survive — `err.code`, `err.status`, whatever your layer attached; - the `stack` survives, unchanged. That last point surprises people. In mainstream engines the stack string is captured **when the Error is constructed**, so a rethrow does not append the rethrow site and does not clear anything. A bare rethrow is therefore invisible in the trace — good for fidelity, mildly annoying when you want to know which layers a failure passed through. ```js try { parse(input); } catch (err) { if (err.code !== 'E_SYNTAX') throw err; // not mine — pass it on untouched return fallback(); } ``` This **conditional rethrow** is the everyday shape: recognise the narrow case you can actually handle, and let everything else past. The alternative — catching broadly and handling generically — is how a `TypeError` from your own typo gets swallowed and reported as "parse failed". ### 2. `throw new Error(err.message);` — lossy wrap Here you construct a brand-new Error. The outer caller receives: - `name === 'Error'` — the original type is gone, so `instanceof MyDomainError` upstream is now false; - no `err.code`, no `err.status` — the properties that made the failure actionable are gone; - a stack rooted at *your catch block*, so the trace points at the translation layer instead of the code that actually failed. And the original object is unreachable: nothing in the language links the new error to it automatically. Wrapping is not wrong in itself. Translating a low-level failure into a boundary-appropriate one is a legitimate design move. What makes it a defect is doing it **destructively**. Since ES2022 the constructor takes an options bag with `cause`: ```js catch (err) { throw new Error('could not load user profile', { cause: err }); } ``` Now the caller gets a message in its own vocabulary *and* can reach the original through `err.cause`. A related trap is `throw new Error(err)` — passing the error itself as the message. The Error constructor converts its first argument to a string, so the message becomes `'Error: original message'`: a duplicated prefix, and everything except the message text discarded. ### 3. Log and return — swallowing ```js catch (err) { console.error(err); return null; // caller believes the call succeeded } ``` This is the most damaging of the three, because it converts a loud failure into a quiet wrong answer. The caller's control flow continues down the success path with a null-ish value; the real symptom appears somewhere else entirely, minutes or screens later, with no link back to the log line. Any check upstream that would have retried, fallen back, or surfaced a message to the user never runs. Swallowing is defensible in exactly one situation: you have genuinely handled the failure — the fallback value is a *correct* result and not a placeholder for "it broke". If a reader cannot tell those two apart from the code, the catch block is a bug. ### A fourth mistake: catch, log, rethrow ```js catch (err) { console.error(err); // logged here throw err; // ...and again at every layer above } ``` This preserves everything, so it is not lossy — it is noisy. Every layer that does it multiplies the log lines for one incident, and the log with the most stack frames is not necessarily the one anyone reads first. Log **once**, at the boundary where the failure stops propagating, and rethrow silently in between. ## The decision rule Ask what the caller can do with what you are about to give it: - **Can't help, can't add context** → `throw err;` - **Can add context that matters at this boundary** → `throw new Error(context, { cause: err });` - **Genuinely handled it, and the value returned is correct** → return, and say so in a comment or the function's name. Everything else — flattening errors into strings, catching broadly to "be safe", returning `null` on failure — trades away the only information anyone will have at 3am.