Proposal: add Control.Exception.SomeAsyncException

It is often useful to distinguish between synchronous and asynchronous exceptions. The common idiom is to run a user-supplied computation catching any synchronous exceptions but allowing asynchronous exceptions (such as user interrupt) pass through. There's no way to know how — synchronously or asynchronously — an exception was thrown, so we have to work around it by relying on the exception type itself. Unfortunately, the AsyncException type was designed as a leaf in the exceptions hierarchy, so it's not possible to extend it with user-defined asynchronous exception types. Thus I propose to add SomeAsyncException as an extensible type ("class") of asynchronous exceptions. It will be a direct subclass of SomeException, and will become the superclass of the existing AsyncException type. Users can then define their own asynchronous exceptions by subclassing SomeAsyncException. My main motivation for this change is exceptions used for timeouts. So the second part of this proposal it to mark System.Timeout.Timeout as an asynchronous exception. Roman

I just discovered that SomeAsyncException under the exact same name and
with the same intention has been added to base-4.7 (GHC 7.8). How cool
is that?
I'll release http://hackage.haskell.org/package/asynchronous-exceptions
which can act as a compatibility package for older bases.
Roman
* Roman Cheplyaka
It is often useful to distinguish between synchronous and asynchronous exceptions. The common idiom is to run a user-supplied computation catching any synchronous exceptions but allowing asynchronous exceptions (such as user interrupt) pass through.
There's no way to know how — synchronously or asynchronously — an exception was thrown, so we have to work around it by relying on the exception type itself.
Unfortunately, the AsyncException type was designed as a leaf in the exceptions hierarchy, so it's not possible to extend it with user-defined asynchronous exception types.
Thus I propose to add SomeAsyncException as an extensible type ("class") of asynchronous exceptions. It will be a direct subclass of SomeException, and will become the superclass of the existing AsyncException type.
Users can then define their own asynchronous exceptions by subclassing SomeAsyncException.
My main motivation for this change is exceptions used for timeouts. So the second part of this proposal it to mark System.Timeout.Timeout as an asynchronous exception.
Roman

On Wed, Feb 5, 2014 at 2:08 AM, Roman Cheplyaka
I just discovered that SomeAsyncException under the exact same name and with the same intention has been added to base-4.7 (GHC 7.8). How cool is that?
In the python world this was called the time machine effect. Looks like the ghc devs have their own time machine! I recently fixed a bug with catching SomeException instead of only synchronous exceptions. I'd imagine that catching async exceptions is very often a bug, since it catches ^C and ThreadKilled and the like. If I did lots of work with exceptions I'd probably go as far as to define an alternate 'catch' that rethrows async exceptions. But I think even with AsyncException as its own class you can't say "everything except", so it still requires an explicit rethrow, yes? E.g.: case Exception.fromException exc of Just (exc :: Exception.AsyncException) -> Exception.throwIO exc Nothing -> return ()

On Feb 5, 2014, at 19:41 , Evan Laforge wrote:
But I think even with AsyncException as its own class you can't say "everything except", so it still requires an explicit rethrow, yes? E.g.:
case Exception.fromException exc of Just (exc :: Exception.AsyncException) -> Exception.throwIO exc Nothing -> return ()
Well, you can do: newtype AllBut e = AllBut SomeException deriving (Show, Typeable) instance forall e . Exception e => Exception (AllBut e) where fromException x = case fromException x :: Maybe e of Nothing -> Just (AllBut x) Just _ -> Nothing This lets you write "foo `catch` \(AllBut _ :: AllBut AsyncException) -> doStuff", which will catch everything *except* async exceptions. Cheers, Merijn

On Feb 5, 2014 10:42 AM, "Evan Laforge"
On Wed, Feb 5, 2014 at 2:08 AM, Roman Cheplyaka
wrote: I just discovered that SomeAsyncException under the exact same name and with the same intention has been added to base-4.7 (GHC 7.8). How cool is that?
I think this is a good enhancement, however I'm of the opinion that "catching all exceptions except async" is an anti-pattern that should usually be avoided. There was a discussion about this on -cafe several months back that I think covers it pretty well. John L.
participants (4)
-
Evan Laforge
-
John Lato
-
Merijn Verstraaten
-
Roman Cheplyaka