<div dir="auto">And just for context for all, here is the previous thread where this discussion originated.<div dir="auto"><br></div><div dir="auto"><a href="https://mail.openjdk.org/pipermail/loom-dev/2025-December/008117.html" target="_blank" rel="noreferrer">https://mail.openjdk.org/pipermail/loom-dev/2025-December/008117.html</a></div><div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 19, 2025, 1:35 AM Eric Kolotyluk <<a href="mailto:eric@kolotyluk.net" target="_blank" rel="noreferrer">eric@kolotyluk.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  

    
  
  <div>
    Hi all,<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    The core questions I’m interested in exploring are along these
    lines:<br>
    <ul>
      <li>How do unchecked exceptions interact with structured
        concurrency’s goal of making lifetimes and failure scopes
        explicit?</li>
      <li>Do exceptions remain the best abstraction for expected failure
        in highly concurrent, compositional code?</li>
      <li>Are there patterns (or emerging idioms) that Loom encourages
        which mitigate long-standing concerns with exceptions — or does
        Loom expose new ones?</li>
      <li>More broadly, should Java be thinking in terms of additional
        failure-handling tools rather than a single dominant model?</li>
    </ul>
    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.<br>
    <br>
    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.<br>
    <br>
    I’m interested in whether error handling deserves a similar
    re-examination in light of Loom’s goals.<br>
    <br>
    Looking forward to the discussion.<br>
    <br>
    Cheers,<br>
    Eric
  </div>

</blockquote></div>