Java's checked exceptions remain controversial, but rather than relitigating whether they're good or bad, this deep-dive focuses on specific pain points and actionable improvements. Key issues covered include: inherited checkedness forcing entire exception hierarchies to be checked when only some should be, overly liberal use of checked exceptions in APIs like InputStream.close(), source-incompatibility when removing checked exceptions, and the fundamental mismatch between checked exceptions and deferred/functional computation (e.g., stream pipelines). Potential fixes discussed include a marker interface to control checkedness at the individual type level, compiler relaxation for catching unthrown exceptions, variadic generics or union types to track multiple exception types in generics, an Either monad for deferred computation scenarios, a JEP draft for switch expressions that can catch exceptions from selector expressions, and stylistic team conventions. The conclusion is that good error handling is inherently hard and no single change will be a silver bullet.
Table of contents
▚ Inherited Checkedness▚ Too Many Checked Exceptions▚ Catching Unthrown Exceptions▚ Functional Error Handling and Deferred Computation▚ Stylistic ChangesSort: