JEP draft: Exception handling in switch

Original Article ↗ Hacker News Discussion ↗

Overall reaction to exception-handling-in-switch

  • Many see it as a good fit for modern, expression-oriented Java, especially with streams and higher-order functions.
  • Some are explicitly enthusiastic, saying it makes checked exceptions more useful and look forward to using it.
  • Others are cautiously positive: useful pattern, clear scoping, “seems like a good idea,” but not ready to declare it unambiguously great.

Exception handling strategies (Java & Kotlin)

  • Two main approaches described:
    • Propagate exceptions and catch at a high level (especially for CLI/backends, where early failure is preferred).
    • Wrap computations into Result<T>-like types (runCatching in Kotlin, libraries such as result4j in Java) and handle errors functionally (favored for GUIs or executor-style code).
  • Some prefer banning propagation only in infrastructural layers (executors, task queues, retries) and otherwise using high-level catching.
  • Others strongly dislike Java’s InterruptedException being checked; claim it clutters code for rare cancellation scenarios.

Checked exceptions, lambdas, and type-system limits

  • Complaint: Java’s checked exceptions don’t compose cleanly with functional APIs (e.g., Consumer in forEach), forcing wrapping into RuntimeException.
  • One view: this stems from missing variadic type parameters; another says the real gap is lack of union types.
  • Workarounds mentioned:
    • Custom ThrowingConsumer with type parameters for thrown exceptions.
    • Helper functions that “uncheck” exceptions for use in streams.

Kotlin Result / runCatching debate

  • Critiques of runCatching:
    • Originally internal to coroutines; now public but considered “half-baked” by some.
    • Catches too broadly (including CancellationException), may hide issues.
    • Can lead to many Result allocations and awkward composition.
  • Counterpoints:
    • Kotlin’s unchecked exceptions don’t signal potential failure at the type level.
    • Standard Result’s restriction to Throwable is seen as clumsy for business logic.
    • Third-party Result libraries are defended as widely used and concurrency-safe.

case throws vs case catch bikeshedding

  • Some argue “case catch” (or bare catch clauses inside switch) is more intuitive and consistent with try/catch.
  • Others defend case throws:
    • Reads as “in case it throws …”.
    • Aligns with pattern-matching over the result of the expression (value, null, or thrown exception).
  • Concerns raised about introducing new keywords like threw; design tries to avoid that.