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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>
