[Haskell-cafe] ANNOUNCE: new installment of failure framework

[Michael Snoyman]

On Tue, Dec 8, 2009 at 11:51 AM, Gregory Crosswhite <
gcross at phys.washington.edu> wrote:

> Michael,
>
> 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
existential types).
* There is no easy way to chain together different types of Eithers (see
below).

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
  checkResult parsed

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.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091208/7c0d7c3b/attachment.html