[Haskell-cafe] exceptions vs. Either

Graham Klyne GK at ninebynine.org
Tue Aug 3 05:19:22 EDT 2004

Two observations:

1. When I recently modified the HaXml XML parser, this is one of the 
significant changes I made:  providing (alterantive) return values based on 
Either, so that input errors could be handled by the invoking function, 
without forcing it into the IO monad.  I guess that's a vote of agreement.

2. I like to distinguish between "expected errors" and "unexpected 
errors".  Having been burned in the past by using exceptions (not FP), I 
try to use them only for conditions that are truly unexpected; i.e. 
_exceptional_.  Bad input, IMO, is something that is not unexpected, so I 
don't really like to handle that via exceptions.


At 13:09 02/08/04 -0700, Evan LaForge wrote:

>Exceptions are convenient in that you can rely on libraries throwing them
>instead of prechecking for valid values yourself (for instance, why check
>that the argument to Char.digitToInt is valid if digitToInt does so already),
>and you don't have to modify a lot of function signatures.  Unfortunately, in
>the face of lazy evaluation, they can get thrown in unexpected places.  Even
>with Exception.evaluate, or code which is already explicitly sequenced in the
>IO monad, like "t <- Exception.evaluate (map Char.digitToInt ['a'..'g'])" an
>exception will only be thrown when you inspect the last element of 't'.
>(digitToInt confusingly accepts hex "digits"---shouldn't it be "higitToInt"
>So it seems to me that if you are, say, checking input, the options are
>to handle exceptions from the checking code but expect them to come from the
>processing code, or decorate all checking code with Rights and Lefts.
>Problems with the first option are that checking code could also trigger some
>exceptions, and Prelude functions throw undescriptive errors like "user
>error" or low level ones like "refuted pattern match" and catching them over
>the entire program means you could stifle a lot of real errors. This implies
>that you have to make specific exceptions and convert Prelude and library
>exceptions into yours as low down as possible, which is cluttering but maybe
>not as cluttering as Either.  Problems with the second option are many of the
>problems that lead to us wanting exceptions in the first place.
>Using Either seems much simpler and functional-friendly.  So then, in what
>contexts are exceptions appropriate in haskell?
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org

Graham Klyne
For email:

More information about the Haskell-Cafe mailing list