--- a/QuerySig.st Sat Nov 09 17:05:11 1996 +0100
+++ b/QuerySig.st Sat Nov 09 17:12:01 1996 +0100
@@ -17,7 +17,7 @@
category:'Kernel-Exceptions'
!
-!QuerySignal class methodsFor:'documentation'!
+!QuerySignal class methodsFor:'documentation'!
copyright
"
@@ -40,10 +40,11 @@
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
+ and nil is returned from the raise
(as opposed to normal signals, which raise an unhandled signal exception).
QuerySignals are also ignored, if a handler exists, but rejects.
- Their main use is to implement up-Queries via signals, that work even
+ Their main use is to implement upQueries via signals, that work even
if intermediate errorSignal handlers are present
(which is not possible with ordinary signals, since errorSignal handlers
would catch those signals).
@@ -59,6 +60,27 @@
Using QuerySignals for this (instead of regular Signals) helps in documenting
the intended usage of those signals.
+ Another use of querySignals is to provide additional information to
+ deeply nested methods, which is only required in the uncommon case;
+ or if another parameter is required by some method, which was not planned
+ for in the beginning, and you do not want to hand this value (via an
+ additional argument) through all intermediate levels.
+ A highly elegant solution to this problem is to provide a handler somewhere
+ at the top of the calling hierarchy, and raise an upQuery from whereever
+ that value is required.
+ A concrete application can be found in the windowGroup- and lastEvent-
+ queries, provided by the windowGroup object. If anyone is interrested
+ in the event which was responible for the anyone to be called, all he needs
+ to do is to raise the lastEventQuerySignal, which returns that event.
+ No intermediate methods are required to know anything about that.
+
+ A final note (to C++ and Java fans):
+ such upQueries are only possible, if the exception handling mechanism
+ does not automatically unwind the stack for the handler invokation.
+ Since the handler must be able to proceed the execution and return
+ a value to the raiser ....
+
+
[see also:]
Signal SignalSet Exception
Object
@@ -271,8 +293,8 @@
"Modified: 14.10.1996 / 16:59:18 / cg"
! !
-!QuerySignal class methodsFor:'documentation'!
+!QuerySignal class methodsFor:'documentation'!
version
- ^ '$Header: /cvs/stx/stx/libbasic/Attic/QuerySig.st,v 1.15 1996-10-14 15:59:28 cg Exp $'
+ ^ '$Header: /cvs/stx/stx/libbasic/Attic/QuerySig.st,v 1.16 1996-11-09 16:12:01 cg Exp $'
! !
--- a/QuerySignal.st Sat Nov 09 17:05:11 1996 +0100
+++ b/QuerySignal.st Sat Nov 09 17:12:01 1996 +0100
@@ -17,7 +17,7 @@
category:'Kernel-Exceptions'
!
-!QuerySignal class methodsFor:'documentation'!
+!QuerySignal class methodsFor:'documentation'!
copyright
"
@@ -40,10 +40,11 @@
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
+ and nil is returned from the raise
(as opposed to normal signals, which raise an unhandled signal exception).
QuerySignals are also ignored, if a handler exists, but rejects.
- Their main use is to implement up-Queries via signals, that work even
+ Their main use is to implement upQueries via signals, that work even
if intermediate errorSignal handlers are present
(which is not possible with ordinary signals, since errorSignal handlers
would catch those signals).
@@ -59,6 +60,27 @@
Using QuerySignals for this (instead of regular Signals) helps in documenting
the intended usage of those signals.
+ Another use of querySignals is to provide additional information to
+ deeply nested methods, which is only required in the uncommon case;
+ or if another parameter is required by some method, which was not planned
+ for in the beginning, and you do not want to hand this value (via an
+ additional argument) through all intermediate levels.
+ A highly elegant solution to this problem is to provide a handler somewhere
+ at the top of the calling hierarchy, and raise an upQuery from whereever
+ that value is required.
+ A concrete application can be found in the windowGroup- and lastEvent-
+ queries, provided by the windowGroup object. If anyone is interrested
+ in the event which was responible for the anyone to be called, all he needs
+ to do is to raise the lastEventQuerySignal, which returns that event.
+ No intermediate methods are required to know anything about that.
+
+ A final note (to C++ and Java fans):
+ such upQueries are only possible, if the exception handling mechanism
+ does not automatically unwind the stack for the handler invokation.
+ Since the handler must be able to proceed the execution and return
+ a value to the raiser ....
+
+
[see also:]
Signal SignalSet Exception
Object
@@ -271,8 +293,8 @@
"Modified: 14.10.1996 / 16:59:18 / cg"
! !
-!QuerySignal class methodsFor:'documentation'!
+!QuerySignal class methodsFor:'documentation'!
version
- ^ '$Header: /cvs/stx/stx/libbasic/QuerySignal.st,v 1.15 1996-10-14 15:59:28 cg Exp $'
+ ^ '$Header: /cvs/stx/stx/libbasic/QuerySignal.st,v 1.16 1996-11-09 16:12:01 cg Exp $'
! !