Since base 4.7, there is a new exception "superclass" SomeAsyncException which all asynchronous exceptions are supposed to extend (via the extensible exceptions mechanism). Adding support for this to syncIO would do two things:
- Add support for user-defined async exceptions
- Make for a more universal definition of async exceptions
Looking at the list of exceptions currently marked as asynchronous, it looks like many of them (like ArithException) are miscategorized, which can lead to incorrect behavior, e.g.:
#!/usr/bin/env stack
-- stack --resolver lts-6.3 runghc --package unexceptionalio
import Control.Exception
import UnexceptionalIO
main :: IO ()
main = syncIO (evaluate (1 `div` 0)) >>= print
Results in a runtime exception:
By contrast, with safe-exceptions:
import Control.Exception (evaluate)
import Control.Exception.Safe
main :: IO ()
main = tryAny (evaluate (1 `div` 0)) >>= print
Results in printing a Left value as expected:
Pinging @Gabriel439 as well, since this affects errors.
Since base 4.7, there is a new exception "superclass"
SomeAsyncExceptionwhich all asynchronous exceptions are supposed to extend (via the extensible exceptions mechanism). Adding support for this tosyncIOwould do two things:Looking at the list of exceptions currently marked as asynchronous, it looks like many of them (like
ArithException) are miscategorized, which can lead to incorrect behavior, e.g.:Results in a runtime exception:
By contrast, with safe-exceptions:
Results in printing a
Leftvalue as expected:Pinging @Gabriel439 as well, since this affects
errors.