# HG changeset patch # User Claus Gittinger # Date 847555921 -3600 # Node ID 05b137a75c751a76779b9383f7129a3494afb0d0 # Parent c8a3af54acb37a4ee1fd2f2a3dd2138ceb0efc53 commentary diff -r c8a3af54acb3 -r 05b137a75c75 QuerySig.st --- 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 $' ! ! diff -r c8a3af54acb3 -r 05b137a75c75 QuerySignal.st --- 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 $' ! !