I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it’s only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.
Pure functions should be referentially transparent; you should be able to replace them with whatever value they evaluate to without changing the semantics of your code.
Throwing is referentially impure: what value do you get from calling x => thrownewRuntimeException()?
Instead, functional languages prefer to return a tagged union of the value or the error.
I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it’s only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.
Pure functions should be referentially transparent; you should be able to replace them with whatever value they evaluate to without changing the semantics of your code.
Throwing is referentially impure: what value do you get from calling
x => throw new RuntimeException()
?Instead, functional languages prefer to return a tagged union of the value or the error.
Sounds good,
but would the preferred way be to use a wrapper type, which holds either the data or the error and avoid exceptions completely?