Addition of a mechanism similar to exceptions allowing the possibly interruptible process of signaling something to a caller and then continuing execution.
Proposed by:Jeff Walker (language designer)
Experts to Contact: Status: Being ConsideredIt is often useful to indicate the occurrence of some event to a caller and then continue on or provide the caller the choice to continue.
Description:Signals operate very much like exceptions. Signals would be sent by:
signal expression;
Signals could then be received by an extension to the try catch mechanism. One would still try the code but then would use receive instead of catch. Signals would pass to receive clauses while exceptions passed to catch clauses. The same rules would apply.
try
statement
receive(identifier:type)
statement
After executing the receive block control would return to after the signal statement. Just as with exceptions it would be necessary to indicate what signals a pattern might send. This would be done with signals clauses as:
signals type-1, type-2, ..., type-n
Signals clauses would act just a throws clauses do for exceptions.
It may be useful to allow signals to be interrupted, in which case they would act like an exception. This would however give the receiver the option of doing so. This might be done by adding a 'interrupt;' statement which when executed in a receive statement would make execution continue after the receive instead of after the signal. It would also be necessary to add some mechanism to control whether a signal may be interrupted.
Alternate implementations would be: Addition of a way to continue after an exception, or an API built on commands and exceptions to achieve the same effect.
Example: