Class: SignalSet

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

Inheritance:

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

Package:

stx:libbasic

Category:

Kernel-Exceptions

Version:

rev: 1.59 date: 2022/07/05 08:28:43

user: stefan

file: SignalSet.st directory: libbasic

module: stx stc-classLibrary: libbasic

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.

copyright
COPYRIGHT (c) 1993 by Claus Gittinger
             All Rights Reserved

This software is furnished under a license and may be used
only in accordance with the terms of that license and with the
inclusion of the above copyright notice.   This software may not
be provided or otherwise made available to, or used by, any
other person.  No title to or ownership of the software is
hereby transferred.

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.

 , anExceptionHandler

add anExceptionHandler 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.

 compact

remove inherited signals of parent signals that are in the set

 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