eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'SignalSet':

Home

Documentation
www.exept.de
Everywhere
for:
[back]

Class: SignalSet


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:

instance creation
o  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:

JavaScript support
o  js_add: anExceptionHandler
( an extension from the stx:libjavascript package )
For JavaScript only:
Alternative error concatenation.
Generated for +-operator in javascript.

adding
o  , anException
add anException to the set

o  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.

queries
o  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.

o  exceptionHandlerFor: anException in: aContext
answer the exceptionHandler for anException from aContext.

o  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

o  handlerProtectedBlock: doBlock inContext: context
set the handlerProtectedBlock in context

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

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

save evaluation
o  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.

o  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
      ]

o  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.'.

o  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
     ]

o  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.

o  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


ST/X 7.2.0.0; WebServer 1.670 at bd0aa1f87cdd.unknown:8081; Thu, 26 May 2022 10:47:43 GMT