There are too many error handling conventions used in library
code!
Robert Dockins
robdockins at fastmail.fm
Wed Mar 14 09:49:55 EDT 2007
On Mar 14, 2007, at 9:33 AM, Simon Marlow wrote:
> ajb at spamcop.net wrote:
>
>> 6. throwDyn
>> 7. ioError and catch
>
> Since deprecating throwDyn was mentioned, I should say that the
> plan I've had in mind has been to merge (6) and (7) by using the
> Exception class:
>
> http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/
> ExtensibleExceptions
> http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf
>
> So there would be just one throw & catch, and you would be able to
> use them with arbitrary types. The scheme suggested in the paper
> is not completely satisfactory, and various people have suggested
> ways to simplify it, so it needs some reworking before I'd call it
> a proposal though.
>
> Just to clarify something I've seen mentioned: throwDyn is *not*
> tied to the IO monad, since it has type Typeable ex => ex -> a.
> However, you can only catch it in the IO monad. So you should
> think of it as a version of 'error' that you can use with something
> other than String.
Since I made the comment, I'll clarify. What I meant is just what
you said: error _recovery_ is tied to the IO monad. The ErrorDynT
proposal I made was a way to get some of the benefits of throwDyn and
still be able to have error recovery in non-IO code.
>
> Cheers,
> Simon
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
More information about the Libraries
mailing list