3 ms·
I find anything but a Result<T, E> ADT to be a poor solution. Errors shouldn't have language-level support (exceptions), and error codes are just a poor impleme
by gorena 11y ago
I find anything but a Result<T, E> ADT to be a poor solution. Errors shouldn't have language-level support (exceptions), and error codes are just a poor implementation of a result ADT - they cannot be enforced by the type system.
Result is a monad, so it doesn't require an alternative code path. It's the cleanest and safest.
"Exceptions" should always be for fatal, irrecoverable errors (array index out of bounds). I'm okay with having them, but I don't think languages should support "catch".
- cousin_it 11y agoHow about using an algebraic effect system? That's sort of a general purpose alternative to monads that also doesn't require an extra code path, and adds a bit of theoretical niceness. For example, if your code can throw two different exceptions, composing two monads is order-sensitive (because the monad interface is in some sense too general and forgets too much), while algebraic effects always commute with each other.
- gorena 11y agoTrue. I could rephrase as "the possibility of errors is just another type, and is best treated as such"?
- deleted 11y ago[deleted]