Closed gbrsales closed 7 years ago
This is intentional behavior, please see the documentation for the safe-exceptions package:
OK, now I understand why handleAsync
was not catching CustomAsync
. For that to work I needed to turn that exception into a child of SomeAsyncException
, like this:
instance Exception CustomAsync where
toException = toException . SomeAsyncException
fromException x = do
SomeAsyncException a <- fromException x
cast a
Maybe you could extend the catchAsync
haddock documentation with a direct link to https://github.com/fpco/safe-exceptions#determining-sync-vs-async. That section was really helpful in explaining what was going on.
Seems like a good change, mind sending a PR?
On Sun, Sep 25, 2016, 7:56 PM gbrsales notifications@github.com wrote:
OK, now I understand why handleAsync was not catching CustomAsync. For that to work I needed to turn that exception into a child of SomeAsyncException, like this:
instance Exception CustomAsync where
toException = toException . SomeAsyncException
fromException x = do SomeAsyncException a <- fromException x cast a
Maybe you could extend the catchAsync haddock documentation with a direct link to https://github.com/fpco/safe-exceptions#determining-sync-vs-async http://url. That section was really helpful in explaining what was going on.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/snoyberg/mono-traversable/issues/109#issuecomment-249432722, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBBwBtTs1wUcXNpznEw0jU04hETiTrks5qtqe5gaJpZM4KEKyr .
I'm using classy-prelude-conduit from lts-7.0.
I would expect the two functions
prelude
andclassyPrelude
in the following code to behave the same, but the second one (classyPrelude
) is not catching the exception. Is this OK?