Are checked exceptions a good language feature? Evaluate the design tradeoffs of the catch-or-declare requirement.

## The premise being evaluated Java is unusual: it has **checked exceptions** and the **catch-or-declare** rule that forces callers to either handle or re-declare them. The design intent (from Java's early days) was that *recoverable, anticipated* failures should be part of a method's **compile-time contract**, so a caller cannot ignore them by accident. This question asks you to judge whether that bet paid off. ## Arguments in favor - **Enforced acknowledgment**: the compiler guarantees the caller knows a method can fail and has to do *something* — handle or propagate. Failures can't be silently dropped (in principle). - **Self-documenting contracts**: the `throws` clause is machine-checked documentation of failure modes, visible at the call site. - **Good for genuinely recoverable conditions**: when the caller really can react (retry, fall back), being reminded is valuable. ## Arguments against - **Leaky abstractions**: a `throws SQLException` from a deep method forces every intermediate layer to either catch or re-declare it, leaking implementation detail upward unless you translate. - **Refactoring fragility**: adding a checked exception to a low-level method can cascade signature changes through many callers — a versioning/maintenance burden, painful for public APIs. - **Encourages swallowing**: the path of least resistance under deadline pressure is an empty or log-only catch, which *defeats* the safety the feature promised. - **Coarsening**: developers write `throws Exception` to stop the cascade, which erases the specific-failure information the feature was meant to provide. - **Poor composition with functional code**: standard functional interfaces (`Function`, `Supplier`, `Stream` operations) don't declare checked exceptions, so lambdas that throw checked exceptions force awkward try/catch-inside-lambda or custom wrappers. This clashes badly with Java 8+ streams. ## The wider language verdict Java is essentially **alone among mainstream modern languages** in enforcing checked exceptions. **C#, Kotlin, Scala, and others deliberately omitted them**, having watched Java's experience. Kotlin interoperates with Java but treats all exceptions as unchecked. This is strong empirical signal that the costs often outweigh the benefits at scale. ## How real codebases cope - **Wrapping to unchecked**: frameworks like **Spring** translate checked exceptions (e.g. `SQLException`) into an unchecked hierarchy (`DataAccessException`), so application code isn't forced into boilerplate. - **Exception translation at boundaries**: catch low-level checked exceptions and rethrow domain-meaningful ones (often unchecked), preserving the cause. - **Sneaky-throws / wrappers** for lambdas, to bridge checked exceptions into functional pipelines. ## A balanced principal-level stance There's no absolute answer; the defensible position is nuanced: - Use **checked** exceptions sparingly, for **truly recoverable, caller-actionable** conditions at a **stable API boundary** where you *want* to force a decision. - Default to **unchecked** for programming errors and for failures the caller usually can't fix, to avoid noise and leakage. - Whatever the policy, handle each failure **once**, at the layer with context, and **never swallow**. - For libraries with many consumers, weigh the refactoring/versioning cost of checked exceptions heavily. ## Deriving the answer Frame it as a tradeoff between *enforced visibility* (the upside) and *boilerplate, leakage, fragility, and poor functional composition* (the downside), note that the rest of the industry largely voted against the feature, and land on: valuable in narrow, deliberate cases; default to unchecked otherwise.