Don´t tried it and probably it does not even compile, but a possibility
could be along these lines:
catchExcept excepts handle e= do
if not . null $ filter ( \(SomeException e') -> typeOf e= typeOf e')
excepts
then throw e
else handle e
use:
u= undefined
excluded= [SomeException (u :: AsyncException), SomeException (u
::ArithException)]
sample= expr `catchExcept` excluded $ do
....
....
2013/7/10 Erik Hesselink <hessel...@gmail.com>
> 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 <mich...@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
>
--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
