You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Erlang, one can deliver a so-called signal to a process, which in Haskell could be represented as an asynchronous exception.
There are two ways a process can currently receive a signal:
From the troupe runtime, e.g., an Exit signal when a linked process exited, or
From another process which used exit to send SomeException to another process.
The built-in exceptions are already SomeAsyncException in the exception hierarchy, however, there's no enforcement of this for callers of exit.
Would it make sense to restrict exit (and, in general, the signal handling code) not to allow for SomeException to be injected, but always enforce SomeAsyncException? Of course, the exitReason field of an Exit message (or exception) should remain Maybe SomeException to support processes exiting due to some synchronous exception.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In Erlang, one can deliver a so-called signal to a process, which in Haskell could be represented as an asynchronous exception.
There are two ways a process can currently receive a signal:
troupe
runtime, e.g., anExit
signal when a linked process exited, orexit
to sendSomeException
to another process.The built-in exceptions are already
SomeAsyncException
in the exception hierarchy, however, there's no enforcement of this for callers ofexit
.Would it make sense to restrict
exit
(and, in general, the signal handling code) not to allow forSomeException
to be injected, but always enforceSomeAsyncException
? Of course, theexitReason
field of anExit
message (or exception) should remainMaybe SomeException
to support processes exiting due to some synchronous exception.When using
safe-exception
'sthrowTo
, if given a synchronous exception, it will be wrapped by an asynchronous one, which is a viable approach: https://hackage.haskell.org/package/safe-exceptions-0.1.7.3/docs/Control-Exception-Safe.html#v:throwToAlternatively,
exit
could raise when given a non-asynchronous exception.0 votes ·
Beta Was this translation helpful? Give feedback.
All reactions