Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Jonas Nordin]

I don't see in what way exceptions can be considered to be side
effects? The fact that they return in a 'differently-structured'
manner doesn't really matter, nor what you call the abstraction that
happens to throw/signal/return them, right?

Unexpected, perhaps - less strict than just disallowing them. And
that's not really feasible either: prove that OOM can't happen? JVM
bugs? Interrupts? Never-returns?

That said, something that might be useful would be a utility type in
the stdlib that could express 'more functional' typing for method
results; perhaps 'ResultOrException<R>'. Or just 'ResultOrFail<R, F>'
- might allow more structured/tighter failure types than just an
exception. Or ResultOrFailOrExn<R, F>. Big design space.

On Fri, Dec 19, 2025 at 2:50 PM Robert Engels <robaho at me.com> wrote:
>
> 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.
>
> On Dec 19, 2025, at 3:37 AM, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>
>