When should you NOT translate an exception, and what are the costs of over-translating across many layers?

## Recap: what translation is and its purpose **Exception translation** = catching a lower-level exception and rethrowing a higher-level one appropriate to the current abstraction, chaining the original as the **cause** (so the 'Caused by:' trace is kept). Its purpose is to stop low-level implementation details from leaking through an API and to give callers errors meaningful at *their* layer. The corollary, often missed, is that translation is a tool to be used *selectively* — not a reflex applied at every method. ## When NOT to translate 1. **The exception is already appropriate to the caller.** If the lower layer already throws a clean, abstraction-level type the caller understands — e.g. Spring's `DataAccessException` hierarchy, a domain `OrderNotFoundException`, or a framework's well-designed exception — wrapping it again adds nothing. Let it propagate. 2. **You'd only re-wrap in an equivalent type.** Translating `DataAccessException` into a `MyDataException` that means the same thing is pure noise: more classes, deeper traces, no new information. 3. **Programming errors should surface honestly.** `NullPointerException`, `IllegalArgumentException`, `IllegalStateException`, `ArrayIndexOutOfBoundsException` indicate *bugs*. Catching and translating them often hides the defect and makes it look like an expected condition. Generally let them propagate (or fix the bug); don't dress them up. 4. **At the very top of the stack** (e.g. a global handler that maps to an HTTP status), you're *handling* and *reporting*, not translating to yet another internal type. 5. **When you can't add value to the message or type** — if you have nothing more specific to say than the original already does, wrapping just lengthens the chain. ## The costs of over-translation Wrapping mechanically at every layer is a recognized anti-pattern: - **Deep, noisy cause chains.** Each wrap adds another `Caused by:` block. A failure that passed through five layers can produce a five-deep chain where the engineer must scroll past four generic wrappers to find the one line that matters (the root cause). Signal-to-noise drops. - **Loss of specificity.** A lower layer may throw a precise subtype (`DuplicateKeyException`). If an intermediate layer catches the broad parent and re-wraps in a flat generic type, that precision is erased for callers above it — they're pushed back to brittle message-string parsing. - **Maintenance burden.** Every translation point is code to write, test, and keep consistent; every new exception class is one more thing in the type system. Mechanical wrapping multiplies both without payoff. - **Performance is usually negligible** (filling in a stack trace has a cost, but it's rarely the issue) — the real cost is *cognitive and architectural*, not CPU. - **Masking risk multiplies.** More catch/rethrow sites mean more chances to forget the cause and mask the original. ## The discipline: translate with intent The rule of thumb (echoing *Effective Java*'s 'throw exceptions appropriate to the abstraction', applied with restraint): translate **at module/API boundaries where the caller's vocabulary genuinely differs**, and to a type the caller can **branch on and act on**. Everywhere else, let an already-appropriate exception flow. As an architect you also set **team conventions** — e.g. 'the persistence module throws the data-access hierarchy; the service module translates only to domain exceptions that the API/controller maps to responses' — so translation happens at a few well-defined seams rather than ad hoc in every method. This keeps cause chains shallow, preserves the most specific type available, and minimizes maintenance. ## Quick checklist - Is the current exception already meaningful to my caller? → don't translate. - Am I adding a more specific/abstraction-appropriate type or message? → translate (and chain). - Is this a programming-error exception? → let it surface; don't disguise it. - Am I about to wrap something I just wrapped one layer down? → stop; one boundary is enough.