[Haskell-cafe] ANNOUNCE: new installment of failure framework
michael at snoyman.com
Tue Dec 8 07:47:47 EST 2009
On Tue, Dec 8, 2009 at 11:51 AM, Gregory Crosswhite <
gcross at phys.washington.edu> wrote:
> Although I like the idea of improving the way that failures are handled in
> Haskell, I am having trouble seeing any reason to use your framework.
> If a function is always assumed to succeed given certain pre-conditions,
> and somewhere along the lines my code discovers that one of these had been
> violated, then I throw an exception in order to communicate to myself the
> manner in which I screwed up.
> If a function might either succeed or fail for a very specific reason, then
> I use a Maybe because the caller will know exactly what problem is being
> signaled by Nothing.
> If a function might fail for one of many reasons and the caller might care
> about learning more about the problem, then I use an Either so that I can
> report the details of the problem.
> In each of the latter two cases, I can already use monads to handle the
> errors in a relatively convenient manner. In the first case I usually want
> the program to die right away and let me know where I screwed up, but if for
> some reason I wanted to continue even given arbitrary unanticipated problems
> in a particular computation the I use an exception handler.
> Given that all of the scenarios that I encounter are already handled by the
> functionality the standard libraries, it is not clear to me what your
> framework actually offers.
> I am not writing this to shoot your framework down, but rather to voice my
> thoughts aloud in order to hear your response to them, since if there is a
> use scenario that I am missing in which your framework would be ideal then I
> would be interested in hearing about it.
> The failure wiki page addresses exactly why Maybe and Either are inadequate
solutions in a number of circumstances. Maybe does not allow any information
to be attached; that may be fine when you directly call a function, but what
if you call a function, which calls another one, and so on and so forth? You
would then have two choices:
* Ultimately just receive a Nothing and not know why.
* At each step of the why, check if it's a Nothing, and then produce some
appropriate message to describe it.
If you choose option 2, you're admitting that Maybe was not sufficient for
your uses any. Regarding Either, there are a number of issues:
* There *is* not Monad instance in the base library. Orphan instances lead
to major issues, such as not being able to import two modules at the same
time because each declares a Monad Either instance.
* With Either, you are limited to a single error type (unless you use
* There is no easy way to chain together different types of Eithers (see
For example, let's say I want to write some code to authenticate a user via
OpenID (see the authenticate package). It has to do at least two things:
* Download pages by HTTP
* Parse the resulting HTML page.
I would like to ideally do the following:
authenticate = do
page <- getPage url
parsed <- parseHtml page
In other words, easily chain things together, and simply let the error types
propogate. If the given functions had these signatures:
getPage :: (MonadFailure HttpException m, MonadIO m) => String -> m String
parseHtml :: Failure ParseHtmlException m => String -> m HtmlTree
checkResult :: Failure AuthenticationException m => HtmlTree -> m Identifier
Then authenticate would simply subsume all these error types, making it
explicit what a client of the libraries needs to be aware of. If clients
instead want to look at it as a simple success/failure, I would recommend
using the attempt package. If they want to deal with each failure type
separately, they could use control-monad-exception.
I hope that clears up why this package exists. It was not born of nothing;
it is meant to solve real problems in an elegant manner. If you have any
questions, please let me know.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe