I think the answer will depend on what you write. If you keep re-throwing exceptions, you wish it was a return value.
If you keep checking the return value to make sure you clean up resources, unlock the locks, invoke the same routine, you wish you had try-with-resources or try/catch/finally. If you write map/reduce, you wish you could supply the monoid for errors just like for values. There are horror stories for all of these cases. On Fri, 19 Dec 2025, 04:55 Eric Kolotyluk, <[email protected]> wrote: > Hi all, > > I’m starting a new thread to continue a discussion that emerged elsewhere, > per mailing list etiquette, and to give the topic a clean and traceable > home. > > My interest here isn’t reactive to any one exchange. I’ve been > experimenting with Loom since its early iterations, and over time it has > sharpened a concern I already had: whether Java’s traditional exception > model remains the right default abstraction in a world of structured > concurrency, virtual threads, and large-scale composition. > > To be clear, this is not a claim that “exceptions are broken” or that Java > should abandon them. Java’s exception system has supported billions of > lines of successful code, and I’ve used it productively for decades. > Rather, Loom makes certain trade-offs more visible — particularly around > control flow, cancellation, failure propagation, and reasoning about > lifetimes — that were easier to ignore in a purely thread-per-task world. > > The core questions I’m interested in exploring are along these lines: > > - How do unchecked exceptions interact with structured concurrency’s > goal of making lifetimes and failure scopes explicit? > - Do exceptions remain the best abstraction for expected failure in > highly concurrent, compositional code? > - Are there patterns (or emerging idioms) that Loom encourages which > mitigate long-standing concerns with exceptions — or does Loom expose new > ones? > - More broadly, should Java be thinking in terms of additional > failure-handling tools rather than a single dominant model? > > I’m not advocating a specific alternative here — just inviting a technical > discussion about whether Loom changes how we should think about error > handling, and if so, how. > > That said, exposure to other ecosystems (e.g., Scala, Kotlin, and more > recently Rust) has broadened how I think about failure modeling. One thing > I’ve consistently appreciated about Java is that it tends to integrate > external ideas deliberately, rather than reflexively rejecting them or > adopting them wholesale. Loom itself is a good example of that approach. > > I’m interested in whether error handling deserves a similar re-examination > in light of Loom’s goals. > > Looking forward to the discussion. > > Cheers, > Eric >
