Proposal: Extensible exceptions

[Ian Lynagh]

On Fri, Jul 04, 2008 at 02:56:06PM +0100, Simon Marlow wrote:
> Ian Lynagh wrote:
> 
> >There's also
> >    ignoreExceptions :: IO () -> IO ()
> >which can be used instead of try for things like
> >    ignoreExceptions (hClose h)
> >(where we don't look at the result, so the exception type would be
> >ambiguous if we used try). (I'm not sure if this is the best name for
> >this function).
> 
> But I think we should omit ignoreExceptions completely, or at least 
> strongly discourage its use.   (I mentioned this to Ian privately, he asked 
> me to bring it up on the list).
> 
> The problem with discarding *any* exception is that it breaks modularity: 
> for example, things like System.Timeout rely on being able to interrupt any 
> computation by using a private exception.  Ignoring exceptions should 
> always be limited to a particular class of exceptions that you want to 
> ignore.  Existing uses of ignoreExceptions should be scrutinised very 
> carefully.

Hmm, I agree, but if people are doing it already (using try) then
they'll presumably keep doing so. And this isn't random newbies, this is
GHC's bootlibs!

Is it better to have a handy function for it, that comes with
documentation telling you not to use it and what to do instead, or to
not provide it and risk people using try with a type sig?

I don't have strong feelings either way.

> In fact, this applies to catchAny too.  It should come with a strong 
> warning, and a suggestion that any unrecognised exceptions should be 
> re-thrown.  Most uses of catchAny are to implement an on-error action 
> anyway, I think this ought to be provided as a combinator.  We have 
> bracketOnError, but perhaps we should also have
> 
>    onException :: IO a -> IO b -> IO a

Sounds good to me.


Thanks
Ian