According to the blog post, this library implements a simple exception hierarchy:
SomeException
|- SomeAsyncException
`- SomeSyncException
and then provides catchAny :: m a -> (SomeSyncException -> m a) -> m a, a specialized version of Control.Exception's catch.
Also quoting from the blog post:
The ideal solution is to make a stronger distinction in the core libraries themselves between sync and async exceptions.
This could be done in two ways:
- SomeException is redefined to mean only synchronous exceptions; a new parent is added containing both SomeException and SomeAsyncException
- SomeException continues its existing behavior; SomeSyncException is added, and all of Hackage is rewritten to use SomeSyncExcepion or SomeAsyncException as appropriate.
I will note the strong similarity between SomeException / SomeAsyncException / SomeSyncException and Java's Throwable / Error / Exception; if (1) is chosen then it would make sense to call the new parent SomeThrowable.
According to the blog post, this library implements a simple exception hierarchy:
and then provides
catchAny :: m a -> (SomeSyncException -> m a) -> m a, a specialized version of Control.Exception'scatch.Also quoting from the blog post:
This could be done in two ways:
I will note the strong similarity between SomeException / SomeAsyncException / SomeSyncException and Java's Throwable / Error / Exception; if (1) is chosen then it would make sense to call the new parent
SomeThrowable.