It's a way of getting context-specific (but not error-specific) behavior, and when dealing with functions producing a polymorphic monadic value it threads very nicely. That said, the approach in Haskell of fail always taking a string (which doesn't necessarily get stored/used anywhere) has a bit less to recommend it. It's also slightly confused conceptually to put "fail" in the Monad typeclass but that mostly bugs the theorists. The biggest downside, though, is that it can often make the source of errors harder to find - cf. hunting NaNs in floating point arithmetic.
Ah, yeah, wasn't as aware of those as I should have been. Still suffers from the "where did that NaN come from?" issue, but looks like good stuff. Any idea why it's not used more?
Haskell actually has three (or four) competing exception handling mechanisms nowadays.
If you use the Either error result approach, you can conceivable put a stack trace (or something similarly identifying) in the Error data-type, so you can avoid the "Where did that NaN come from?" issue.
I think we need to see Algebraic data types in more languages, before we will see this approach used more often. (In my opinion algebraic datatypes and the pattern matching they enable rank in the same league as garbage collection in that they are a feature originally invented in and for functional languages, but useful outside as well.)
> Haskell actually has three (or four) competing exception handling mechanisms nowadays.
Yeah, knew about Either in general (see my top-level comment about sums vs. products), just not the monadic bits around it (MonadError and ErrorT, in particular).
> If you use the Either error result approach, you can conceivable put a stack trace (or something similarly identifying) in the Error data-type, so you can avoid the "Where did that NaN come from?" issue.
True - even just making exceptions take a Loc parameter seems like it could be a good step, but that would be basically requiring TemplateHaskell, which would ruffle feathers for sure...
> I think we need to see Algebraic data types in more languages, before we will see this approach used more often. (In my opinion algebraic datatypes and the pattern matching they enable rank in the same league as garbage collection in that they are a feature originally invented in and for functional languages, but useful outside as well.)
I agree wholeheartedly. Lack of easy-to-use algebraic datatypes is my biggest pain-point in languages that lack 'em.
