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