Proposal: Extensible exceptions
marlowsd at gmail.com
Fri Jul 4 09:56:06 EDT 2008
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
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
More information about the Libraries