QuerySignal.st
author Claus Gittinger <cg@exept.de>
Tue, 23 Apr 1996 22:22:39 +0200
changeset 1275 2079f4776628
parent 1249 2d5d0edd3359
child 1292 89497fff7f87
permissions -rw-r--r--
checkin from browser

"
 COPYRIGHT (c) 1995 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.
"

Signal subclass:#QuerySignal
	instanceVariableNames:''
	classVariableNames:''
	poolDictionaries:''
	category:'Kernel-Exceptions'
!

!QuerySignal class methodsFor:'documentation'!

copyright
"
 COPYRIGHT (c) 1995 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.
"
!

documentation
"
    QuerySignals are like signals, except that they are not accepted
    by handlers for ordinary signals.
    I.e. a signal handler for a normal signal will not handle a query
    signal. Thus, these bypass anySignal handlers.
    If unhandled, no error is raised, instead they are simply ignored
    (as opposed to normal signals, which raise an unhandled signal exception).

    Their main use is to implement up-Queries via signals even if intermediate
    errorSignal handlers are present (which is not possible with ordinary signals).
    Code deep down in the calling hierarchy can post such an up-Query to ask
    for some information in return or to pass some information upward. 

    For example, the activityNotification mechanism is built on top of this:
    everyone can send such a notification which is either handled by someone
    up in the hierarchy (to show it in the windows info area) or simply
    ignored.

    Using QuerySignals for this (instead of regular Signals) helps in documenting
    the intended usage of those signals.

    [see also:]
        Signal SignalSet Exception
        Object
"
!

examples 
"
    an up-query from a deeply nested operation to a higher level:

	|querySignal zero|

	zero := 0.
	querySignal := QuerySignal new.
	querySignal handle:[:ex |
	    ex proceedWith:true
	] do:[
	    'nexting'.
	    [
		[
		    Object errorSignal handle:[:ex |
			ex proceed
		    ] do:[
			[
			    1 // zero.  'a cought error'.
			    (querySignal raise) ifTrue:[
				Transcript showCr:'query says: ok'.
			     ] ifFalse:[
				Transcript showCr:'query says: no'
			     ]
			] value
		    ]
		] value
	    ] value
	]
"
! !

!QuerySignal methodsFor:'queries'!

accepts:aSignal
    "return true, if the receiver accepts the argument, aSignal.
     (i.e. the receiver is aSignal or a parent of it). False otherwise."

    |s|

    aSignal isQuerySignal ifFalse:[^ false].

    s := aSignal.
    [s notNil] whileTrue:[
	self == s ifTrue:[^ true].
	s := s parent
    ].
    ^ false
!

isQuerySignal
    "return true, if this is a querySignal - always return true here"

    ^ true

    "Modified: 22.4.1996 / 13:45:10 / cg"
! !

!QuerySignal class methodsFor:'documentation'!

version
    ^ '$Header: /cvs/stx/stx/libbasic/QuerySignal.st,v 1.8 1996-04-23 20:22:39 cg Exp $'
! !