[Haskell] IO, exceptions and error handling

[Graham Klyne]

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 
diagnostic.

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.

#g
--

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.
>
>http://research.microsoft.com/~simonpj/Papers/imprecise-exn.htm
>
>--KW 8-)
>--
>Keith Wansbrough <kw217 at cl.cam.ac.uk>
>http://www.cl.cam.ac.uk/users/kw217/
>University of Cambridge Computer Laboratory.

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact