Is there a consensus on how anticipatable failure situations should be handled? 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, etc? 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? Cheers Daniel