Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Robert Engels]

All errors including exceptions are side effects. A pure function requires the same result for the same inputs - obviously any IO breaks this. 

> On Dec 19, 2025, at 8:29 AM, Jonas Nordin <jonas.j.nordin at gmail.com> wrote:
> 
> 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:
>> 
>>