What is the difference between exception translation, exception chaining, and exception masking (swallowing)?

## Three terms, three meanings These words get used interchangeably in interviews but mean distinct things. ### 1. Exception translation **What:** catching a low-level exception and throwing a *different, higher-level* exception that fits the current abstraction layer. It's about the **type** the caller sees. Example: catch `SQLException`, throw `DataAccessException`. ### 2. Exception chaining **What:** the **mechanism** of linking the original exception to the new one as its *cause*. In Java, every `Throwable` has an optional `cause`. You set it via: - the standard constructor: `new MyException("message", originalException)` - or `myException.initCause(originalException)` if no such constructor exists. The cause is printed in stack traces as a `Caused by:` block. Chaining is what makes translation safe — you change the type *without throwing away* the evidence. Translation and chaining almost always go together: you translate the type and chain the cause. ```java try { parse(input); } catch (NumberFormatException e) { throw new ConfigException("Invalid port in config", e); // translate (new type) + chain (e as cause) } ``` ### 3. Exception masking (a.k.a. swallowing / shadowing) **What:** an **anti-pattern** where the original exception's information is *lost*. Forms: - **Swallowing:** `catch (Exception e) { }` — caught and ignored entirely. The error vanishes. - **Translating without chaining:** `throw new ConfigException("bad config");` — a new exception is thrown but the original `e` is not passed as cause, so you lose the real reason. - **Overwriting in finally:** if the `try` block throws exception A and the `finally` block then throws exception B, the JVM propagates B and **A is lost**. The same can happen when closing a resource throws while the body already failed. ## The finally/close masking trap and 'suppressed' exceptions Consider: ```java try { throw new IOException("real problem"); } finally { throw new RuntimeException("cleanup failed"); // this WINS; IOException is lost } ``` The `IOException` — the real cause — is silently discarded. To address this, Java 7 added the **suppressed-exception** mechanism: `Throwable.addSuppressed(Throwable)` and `getSuppressed()`. **try-with-resources** uses it automatically: if the body throws and then `close()` also throws, the body's exception propagates as primary and the `close()` exception is attached as a *suppressed* exception (shown as `Suppressed:` in the trace) — nothing is lost. This is why try-with-resources is preferred over manual try/finally for closing resources. ## How they relate - **Translation + chaining = the correct pattern.** Change the type for abstraction cleanliness; keep the cause for diagnostics. - **Translation WITHOUT chaining = masking.** A surprisingly common bug — you intended to translate but destroyed the evidence. - **Chaining without translation** is possible (wrap in a generic `RuntimeException(e)`) but pointless if the wrapper adds no abstraction value; it just deepens the trace. ## Practical rules 1. Never swallow: an empty catch must be justified with a comment and usually logged. 2. Always pass the cause when rethrowing. 3. Use try-with-resources so cleanup failures become *suppressed*, not masking, exceptions. 4. Don't let `finally` throw; if cleanup can fail, handle it inside the finally.