Proposal: Extensible exceptions
igloo at earth.li
Fri Jul 4 14:52:21 EDT 2008
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
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
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.
More information about the Libraries