IOError vs. Exception vs. IOException

John Meacham
Fri, 15 Nov 2002 13:39:11 -0800

I actually meant relax the haskell 98 spec in the quite literal sense of
changing the spec to allow for the set of exceptions to be undefined.
the only requirement should be that 'isHaskell98Exception' (or whatever)
is accurate so unknown errors can be rethrown and the exceptions
mentioned in the report exist (even if they are not thrown in a given
implementation). It would encourage good programing techniques anyway,
(testing for specific exceptions rather than doing a 'catch-all'). 

on another note, when i catch and want to rethrow an exception, should i
use ioError or throw? does it matter in an exception handler?

On Fri, Nov 15, 2002 at 10:01:18AM -0000, Simon Marlow wrote:
> > Just a thought, but what are the ramifications of taking the other
> > route, relaxing the haskell 98 spec to allow implementations to expand
> > the set of valid exceptions? a function can be used to 
> > determine whether
> > it is something not covered by the haskell 98 spec (even if 
> > we dont know
> > anything else about it..) and we can at least rethrow it or 
> > 'show' it in
> > logs or whatever. lots of useful little functions can be written which
> > are haskell 98 but should be general enough to handle random 
> > exceptions,
> > it would be silly to have to keep 2 versions around...
> <snip>
> It's difficult to "relax the Haskell 98 spec" in this way, since most
> compilers can be used in a strict Haskell 98 mode.  Up to now this
> hasn't required using a different set of libraries, but if
> -fglasgow-exts changed the meaning of IO.catch then it would.
> Instead, I'd suggest deprecating System.IO.catch and perhaps the rest of
> the IOError support in System.IO.  It is all available from
> System.IO.Error and Control.Exception anyhow.
> Cheers,
> 	Simon
> _______________________________________________
> Libraries mailing list

John Meacham - California Institute of Technology, Alum. -