How do checked exceptions create leaky abstractions, and how does exception translation (wrapping) address this when designing custom exceptions?

## What 'abstraction' and 'leaky abstraction' mean An **abstraction** is an interface that hides how something is done so callers depend only on *what* it does. A `UserRepository.findById(id)` should let callers think 'fetch a user' without knowing whether it's backed by SQL, a file, or a web service. An **abstraction leaks** when implementation details escape through the interface and force callers to depend on them. ## How checked exceptions leak Checked exceptions are part of a method's *signature* (the `throws` clause), and the compiler propagates the obligation up the call chain. If a JDBC-backed repository method is declared `List<User> findAll() throws SQLException`, then: - Every caller must catch or re-declare `SQLException`. - `SQLException` is a JDBC concept — so the service layer, and even controllers, now 'know' the repository uses JDBC. - If you migrate to MongoDB, the signature must change to throw something else, and **every caller breaks**, even though conceptually nothing about 'fetch users' changed. That upward, compiler-enforced propagation of an implementation-specific type *is* the leak. (Unchecked exceptions can leak conceptually too, but they don't force the signature change, so the coupling is softer and the migration doesn't break compilation.) ## Exception translation (a.k.a. wrapping / chaining) The fix, recommended in *Effective Java* ("higher layers should catch lower-level exceptions and throw exceptions explainable in terms of the higher-level abstraction"), is **exception translation**: at the abstraction boundary, catch the low-level exception and throw one that belongs to your layer. ```java public List<User> findAll() { try { return jdbc.query(SQL, rowMapper); } catch (SQLException e) { // translate: layer-appropriate, and unchecked to clean the signature throw new UserRepositoryException("Failed to load users", e); } } ``` Key points: - The new exception is described in terms of *your* domain ('failed to load users'), not JDBC. - You pass the original `e` as the **cause** (second constructor arg, or `initCause`). This is **exception chaining**: the root cause and its stack trace are preserved and printed, so you don't lose debuggability. - You can make the new exception **unchecked**, which removes the leaky `throws` from the signature entirely. Switching the backing store now changes only the repository internals; callers are untouched. ## Chaining vs swallowing - **Chaining (good):** `throw new X("msg", cause)` — keeps the original for diagnosis. - **Losing the cause (bad):** `throw new X("msg")` — discards why it failed; you'll debug blind. - **Swallowing (worst):** `catch (SQLException e) {}` — empty catch, the failure vanishes. Checked exceptions are *especially* prone to this because the compiler nags you and the lazy fix is an empty catch. ## The canonical real-world example: Spring Spring's data access layer catches the checked, vendor-specific `SQLException` and translates it into its own **unchecked** `DataAccessException` hierarchy (e.g. `DuplicateKeyException`, `DataIntegrityViolationException`). This: - removes checked-exception boilerplate from application code, - makes the API technology-neutral (JDBC, JPA, etc. map into the same exceptions), - classifies errors meaningfully rather than dumping a single opaque `SQLException`. Hibernate similarly turns checked persistence errors into unchecked ones. ## When NOT to translate Translation has a cost — every layer that wraps adds a frame and a maintenance point. Guidelines: - **Wrap at meaningful boundaries** (e.g. persistence→service, integration→domain), not at every method. - **Don't translate just to translate** — if the lower exception is already abstraction-appropriate, let it propagate. - **Never drop the cause.** Wrapping without chaining defeats the purpose. - **Avoid over-wrapping** that produces nested 'caused by ... caused by ...' chains five deep with no added meaning. - Prefer translating low-level checked exceptions into **unchecked** higher-level ones in most modern designs, so the abstraction stays clean. ## Why this matters for custom exception design When you design a custom exception, part of its job is to be the *target* of translation — the layer-appropriate type that hides the messy lower-level cause. Designing it with a `(String message, Throwable cause)` constructor (and ideally making it unchecked) is what lets you wrap cleanly. This is how you get the contract clarity of a named domain exception without the leaky-abstraction cost of propagating raw implementation exceptions.