[Haskell-cafe] exceptions vs. Either
GK at ninebynine.org
Tue Aug 3 05:19:22 EDT 2004
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
More information about the Haskell-Cafe