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