There are too many error handling conventions used in library code!

Robert Dockins robdockins at
Wed Mar 14 09:49:55 EDT 2007

On Mar 14, 2007, at 9:33 AM, Simon Marlow wrote:

> ajb at 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:
> ExtensibleExceptions
> 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