<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">I’ll disagree with the last case. The number one reason functional programming is a mess is because people don’t exclusively use it with pure functions. Errors or Exceptions are side effects. You can map them to a value and try and call it a function but it’s not. Use map/reduce with pure functions and it works fine. </div><div dir="ltr"><br><blockquote type="cite">On Dec 19, 2025, at 3:37 AM, Alex Otenko <oleksandr.otenko@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">I think the answer will depend on what you write.<div dir="auto"><br></div><div dir="auto">If you keep re-throwing exceptions, you wish it was a return value.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">If you write map/reduce, you wish you could supply the monoid for errors just like for values.</div><div dir="auto"><br></div><div dir="auto">There are horror stories for all of these cases.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 19 Dec 2025, 04:55 Eric Kolotyluk, <<a href="mailto:eric@kolotyluk.net">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>
</div></blockquote></body></html>