[Haskell] IO, exceptions and error handling
gk at ninebynine.org
Mon Jun 14 10:57:54 EDT 2004
Now I see it. Thanks.
Thanks also for the reference. Nice paper!
So now where do I stand?
I still think that being forced to handle exceptions in the IO monad is
(sometimes) inconvenient, but I can now see why it is required for a
rigorous language semantics. My problem relates to wanting to be able to
effect some level of recovery in one library component for errors that
arise in another. I thought about returning the entire set of exceptions,
but I see that the implementation penalty is probably too high.
I assume the suggested mapException function [sect 5.4] remains
unproblematic ... is it (or some equivalent) actually implemented? I could
imagine it being useful for mapping errors into a common framework; e.g.
to catch exceptions from an XML parser and return a common "XML error"
exception, incorporating information from the original as additional
I think that the suggested unsafeIsException is appealing, since it allows
some level of recovery action without (I think) opening up the insecurities
of unsafePerformIO. The idea that the semantics of programs that do no
raise exceptions is not affected is particularly appealing.
At 14:46 14/06/04 +0100, Keith Wansbrough wrote:
> > I can't see any fundamental reason why exception handling has to occur in
> > the IO monad.
>Read the paper _A Semantics for Imprecise Exceptions_. The problem is
>that the evaluation order of Haskell would have to be fixed for this not
>to lose referential transparency. What is the value of
>catchExcept (show (makeExcept "E1" + makeExcept "E2")) (\x -> x)
>? Haskell wouldn't be "purely functional" any more.
>Keith Wansbrough <kw217 at cl.cam.ac.uk>
>University of Cambridge Computer Laboratory.
More information about the Haskell