Hi Michael,

We do this as well. In addition to AsyncException, we ignore
BlockedIndefinitelyOnSTM, BlockedIndefinitelyOnMVar and Deadlock. I'm
not sure you can ignore Timeout, since the type is not exported from
System.Timeout. I'm not sure how to classify these, though. They are
in some sense non-recoverable: restarting whatever the thread was
doing is not the right thing to do.

Erik

On Wed, Jul 10, 2013 at 8:28 AM, Michael Snoyman <michael@snoyman.com> wrote:
> There's a pattern that arises fairly often: catching every exception thrown
> by code. The naive approach is to do something like:
>
>     result <- try someCode
>     case result of
>         Left (e :: SomeException) -> putStrLn $ "It failed: " ++ show e
>         Right realValue -> useRealValue
>
> This seems perfectly valid, except that it catches a number of exceptions
> which seemingly should not be caught. In particular, it catches the async
> exceptions used by both killThread and timeout.
>
> I think it's fair to say that there's not going to be a single function that
> solves all cases correctly, but it is a common enough situation that people
> need to write code that resumes work in the case of an exception that I
> think we need to either have some guidelines for the right approach here, or
> perhaps even a utility function along the lines of:
>
>     shouldBeCaught :: SomeException -> Bool
>
> One first stab at such a function would be to return `False` for
> AsyncException and Timeout, and `True` for everything else, but I'm not
> convinced that this is sufficient. Are there any thoughts on the right
> approach to take here?
>

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe