There are too many error handling conventions used in library
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:
> 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.
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
More information about the Libraries