Class: SignalSet

• Inheritance
• Description
• Related information
• Class protocol
  • instance creation
• Instance protocol
  • JavaScript support
  • adding
  • queries
  • save evaluation
• Private classes

Inheritance:

   Object
   |
   +--Collection
      |
      +--Set
         |
         +--IdentitySet
            |
            +--SignalSet
               |
               +--SignalSet::SetOfAnySignal

Package:

stx:libbasic

Category:

Kernel-Exceptions

Version:

rev: 1.54 date: 2019/03/13 09:30:08

user: cg

file: SignalSet.st directory: libbasic

module: stx stc-classLibrary: libbasic

Author:

Claus Gittinger

Description:

SignalSet allows catching of multiple signals. A SignalSet consists of
a number of signals and also implements the #handle:do: and #catch: methods
just as signals do.
However, any signal from the SignalSet will, if signalled, lead into the handler.

There is also a special signalSet, which can be used to catch any
signal in the system - but this should no longer be used, since catching
Object>>errorSignal has now the same effect.

For more detail, see comment in Signal and examples in doc/coding.

Notice: SignalSets are not needed when a group of children of a common signal
(such as arithmeticSignal) is to be handled; the parent signal of those will
also handle all children.
Use signalSets if totally unrelated signals should be handled by one common
handler.

Related information:

    Exception
    Signal
    QuerySignal
    Object

Class protocol:

 anySignal

return a special signalSet for catching any signal.
Questionable:
you should use 'Object>>errorSignal' for that purpose;
however, the anySignal-set also catches nonChilds of the ErrorSignal
(i.e. highly private, strange signals).

Instance protocol:

 js_add: anExceptionHandler
( an extension from the stx:libjavascript package )

For JavaScript only:
Alternative error concatenation.
Generated for +-operator in javascript.

 , anException

add anException to the set

 add: anExceptionHandler

Check, that only exceptionHandlers are added.
Very bad (recursive) things may happen if e.g. #accepts: is called
and raises a MessageNotUnderstood error.

 accepts: aSignalOrExceptionClass

return true, if the receiver accepts the argument, aSignal.
(i.e. if any of the receiver's elements is aSignal or a parent of it).
False otherwise.

 exceptionHandlerFor: anException in: aContext

answer the exceptionHandler for anException from aContext.

 handlerForSignal: signal context: theContext originator: originator

answer the handler block for the signal from originator.
The block is retrieved from aContext.
Answer nil if the signal is not handled

 handlerProtectedBlock: doBlock inContext: context

set the handlerProtectedBlock in context

 handles: anException

return true, if the receiver handles the argument, anException.
(i.e. if any of the receiver's elements handles anException).

 isExceptionHandler

return true, if the receiver responds to the exception handler protocol,
especially to the #accepts: and #handles: messages

 answer: someAnswer do: aBlock

evaluate the argument, aBlock.
If the receiver is queried during evaluation, answer and proceed with someAnswer.
This is a wrapper for #handle:do: for lazy typists; no new functionality.

 catch: aBlock

evaluate the argument, aBlock.
If any of the signals in the receiver is raised during evaluation,
abort the evaluation and return true; otherwise return false.
With the special anySignal, evaluation can be performed totally save
from signals - but who (beside radical c++ fans) would do that ?

usage example(s):

SignalSet anySignal catch:[ (#(1 2 3 4) at:5) / 0.0 ]

 deferAfter: aBlock

evaluate the argument, aBlock.
Ignore the receiver-signal during evaluation - i.e. simply continue,
but remember if the signal was raised.
After the block evaluation, finally raise the signal - if it was raised in the block.
If the signal is raised multiple times, only the first raises parameter is remembered,
and only a single raise is performed after the block's evaluation.

Deferring makes sense for some signals, such as UserInterrupt or AbortSignal,
which must occasionally be delayed temprarily until a save place is reached
(especially when packages are sent across a communication channel, and you don't want
partial packages to be generated by user interruptions).

usage example(s):

(UserInterrupt , AbortOperationRequest) deferAfter:[ Transcript showCR:'1 - now raising, but will be deferred.'. UserInterrupt raiseRequestWith:'hello'. Transcript showCR:'2 - after the raise, deferred exception will be handled soon.'. ]. Transcript showCR:'3 - here after the protected block.'.

 handle: handleBlock do: aBlock

evaluate the argument, aBlock.
If any of the signals in the receiver is raised during evaluation,
evaluate the handleBlock passing it an Exception argument.
The handler may decide how to react to the signal by sending
a corresponding message to the exception (see there).
If the signal is not raised, return the value of evaluating
aBlock.

usage example(s):

SignalSet anySignal handle:[:ex | ex errorString print. ' occurred in: ' print. ex suspendedContext printNL. ex return ] do:[ (#(1 2 3 4) at:5) / 0.0 ] SignalSet anySignal handle:[:ex | ex errorString print. ' occurred in: ' print. ex suspendedContext printNL. self bar. ex return ] do:[ (#(1 2 3 4) at:5) / 0.0 ]

 handle: handleBlock from: anObject do: aBlock

evaluate the argument, aBlock.
If any of the signals in the receiver is raised during evaluation,
and the exception originated from anObject,
evaluate the handleBlock passing it an Exception argument.
The handler may decide how to react to the signal by sending
a corresponding message to the exception (see there).
If the signal is not raised, return the value of evaluating
aBlock.

 ignoreIn: aBlock

evaluate the argument, aBlock.
Ignore any signal from the receiver during evaluation - i.e. simply continue with the default resume value.
This makes only sense for some signals, such as UserInterrupt
or AbortOperationRequest, because continuing after an exception without any cleanup
will often lead to followup-errors.

usage example(s):

SignalSet anySignal ignoreIn:[ 123 size open ]

Private classes:

    SetOfAnySignal