Proposal: Extensible exceptions

[Simon Marlow]

Ian Lynagh wrote:

> This is a proposal to replace the current exception mechanism in the
> base library with extensible exceptions.

I'm generally in favour of this (of course) ...

> 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.

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

Cheers,
	Simon