And just for context for all, here is the previous thread where this discussion originated.
https://mail.openjdk.org/pipermail/loom-dev/2025-December/008117.html You can start reading from there. A few more replies later, and then this new thread was created, so as not to distract from the other topic. On Fri, Dec 19, 2025, 1:35 AM 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 >
