[Haskell-cafe] error vs. MonadError vs. fail
dagda at xtra.co.nz
Sun Mar 26 21:53:58 EST 2006
Is there a consensus on how anticipatable failure situations should be
There was a thread, "haskell programming guidelines", from 2006-02-25 where
John Meacham and Cale Gibbard had a bit of back-and-forth about using
Monad.fail or a purpose specific MonadFail class.
I believe a consensus was reached that using error should only be for
'impossible' situations and signaling buggy code.
[Apologies if I've put words in anyones mouth.]
Using fail certainly seems quick and easy, but I find it a bit distasteful for
a few different reasons:
users of a library can't discriminate between a failure indicating they've
supplied bad input and a failure indicating that teh library writer has got a
bad pattern match somewhere,
it doesn't seem to force the potential for failure to be explicit in the api
of a library,
it doesn't seem to allow distinct, and rich, failure constructs at system
layer boundaries, or the containment of them.
Maybe the last two aren't a problem when programming in Haskell, but by itself
the first seems pretty nasty.
Apparently the advantage of fail is that user of the library can choose to
receive failures as eg Maybes, Eithers, , or whatever they like.
But surely a MonadFail could allow the best of both worlds, letting the
library throw as detailed an error construct as it can, and letting the
library user choose MonadFail instance such that error constructs are turned
into Maybes, Eithers, a new construct appropriate for a higher system layer,
MonadError is not up to this task as far as I can tell. Has anybody whipped
up an alternative, or can explain why it can't be done?
More information about the Haskell-Cafe