What is exception translation in Java, and why would you do it instead of just letting a low-level exception propagate?

## The problem exception translation solves In Java, an **exception** is an object thrown to signal that something went wrong; it travels up the call stack until some `catch` block handles it. A **checked exception** must be declared in a method's `throws` clause and the caller is forced to handle or re-declare it; an **unchecked exception** (a subclass of `RuntimeException`) does not have to be declared. Real systems are built in **layers** (also called *abstraction levels*). A typical stack: a web controller calls a service, the service calls a repository (data-access layer), and the repository talks to a database via JDBC. Each layer has its own vocabulary — the controller thinks in HTTP, the repository thinks in 'rows and entities', JDBC thinks in `SQLException`. If a low-level exception like `java.sql.SQLException` is allowed to fly all the way up untouched, every caller above the repository is now coupled to JDBC. Their code must import `SQLException`, their `catch` blocks reference it, and their method signatures may have to declare it. This is called a **leaky abstraction**: implementation details (here, 'we use SQL') escape through the API and force the rest of the system to know about them. ## What exception translation is **Exception translation** is the practice of *catching* a lower-level exception and *throwing a new, higher-level exception that is appropriate to the abstraction the current layer presents*. The repository catches `SQLException` and throws, say, `DataAccessException` (a higher-level type the rest of the app understands). The caller now only ever sees `DataAccessException`, which means 'something went wrong reading/writing data' — without knowing or caring that SQL was involved. ```java public User findById(long id) { try { return jdbc.queryForUser(id); } catch (SQLException e) { throw new DataAccessException("Failed to load user " + id, e); // higher-level, e chained as cause } } ``` The phrase 'appropriate to the abstraction' is the heart of it. The thrown type should make sense in the *caller's* world. A `UserService` that fails to find a user might translate further to a domain-level `UserNotFoundException`. ## Why do it (the benefits) 1. **Stable API contract.** The exceptions a method can throw are part of its public contract. If you swap the implementation (JDBC → JPA/Hibernate, or a SQL DB → a NoSQL store), the low-level exception types change. If callers caught those, they'd all break. Translating to a stable higher-level type insulates them. 2. **No leaking of implementation details.** Callers don't learn that you use SQL, a particular driver, a file, or a remote API. This keeps modules decoupled. 3. **Meaningful errors.** A `DataAccessException` or `OrderProcessingException` tells the caller something actionable at their level; a raw `SocketTimeoutException` does not. 4. **Cleaner caller code.** Callers don't have to import or handle a zoo of low-level types from layers they shouldn't know about. ## The non-negotiable rule: chain the cause When you throw the new exception, you must pass the original as the **cause**. In Java this is done via the constructor `new HighLevelException(message, cause)` or `initCause(cause)`. The cause is preserved and printed in the stack trace as a 'Caused by:' section, so you keep *all* the diagnostic detail (the real SQL error, the line it failed on). Throwing a new exception *without* the cause is **exception masking** — you destroy the evidence and make debugging far harder. This is the single most common mistake. ## How it differs from blind propagation - **Blind propagation** = let the original exception keep flying (or re-throw it as-is). Cheap, but leaks the low-level type upward. - **Translation** = deliberately convert to a layer-appropriate type *and chain the original*. Costs a little code but keeps abstractions clean. Translation is not free: each wrap adds a layer to the stack trace and a class to maintain. So **translate only where it adds meaning** — typically at module/layer boundaries — not mechanically at every method. Over-wrapping produces deeply nested 'Caused by' chains that are noise. This idea is widely cited (Effective Java, Item 'Throw exceptions appropriate to the abstraction'). Spring's `DataAccessException` hierarchy is a canonical production example: it translates vendor-specific `SQLException`s into a consistent, unchecked, technology-agnostic hierarchy.