38 QuerySignals are like signals, except that they are not accepted |
38 QuerySignals are like signals, except that they are not accepted |
39 by handlers for ordinary signals. |
39 by handlers for ordinary signals. |
40 I.e. a signal handler for a normal signal will not handle a query |
40 I.e. a signal handler for a normal signal will not handle a query |
41 signal. Thus, these bypass anySignal handlers. |
41 signal. Thus, these bypass anySignal handlers. |
42 If unhandled, no error is raised, instead they are simply ignored |
42 If unhandled, no error is raised, instead they are simply ignored |
|
43 and nil is returned from the raise |
43 (as opposed to normal signals, which raise an unhandled signal exception). |
44 (as opposed to normal signals, which raise an unhandled signal exception). |
44 QuerySignals are also ignored, if a handler exists, but rejects. |
45 QuerySignals are also ignored, if a handler exists, but rejects. |
45 |
46 |
46 Their main use is to implement up-Queries via signals, that work even |
47 Their main use is to implement upQueries via signals, that work even |
47 if intermediate errorSignal handlers are present |
48 if intermediate errorSignal handlers are present |
48 (which is not possible with ordinary signals, since errorSignal handlers |
49 (which is not possible with ordinary signals, since errorSignal handlers |
49 would catch those signals). |
50 would catch those signals). |
50 |
51 |
51 Code deep down in the calling hierarchy can post such an up-Query to ask |
52 Code deep down in the calling hierarchy can post such an up-Query to ask |
56 up in the hierarchy (to show it in the windows info area) or simply |
57 up in the hierarchy (to show it in the windows info area) or simply |
57 ignored. |
58 ignored. |
58 |
59 |
59 Using QuerySignals for this (instead of regular Signals) helps in documenting |
60 Using QuerySignals for this (instead of regular Signals) helps in documenting |
60 the intended usage of those signals. |
61 the intended usage of those signals. |
|
62 |
|
63 Another use of querySignals is to provide additional information to |
|
64 deeply nested methods, which is only required in the uncommon case; |
|
65 or if another parameter is required by some method, which was not planned |
|
66 for in the beginning, and you do not want to hand this value (via an |
|
67 additional argument) through all intermediate levels. |
|
68 A highly elegant solution to this problem is to provide a handler somewhere |
|
69 at the top of the calling hierarchy, and raise an upQuery from whereever |
|
70 that value is required. |
|
71 A concrete application can be found in the windowGroup- and lastEvent- |
|
72 queries, provided by the windowGroup object. If anyone is interrested |
|
73 in the event which was responible for the anyone to be called, all he needs |
|
74 to do is to raise the lastEventQuerySignal, which returns that event. |
|
75 No intermediate methods are required to know anything about that. |
|
76 |
|
77 A final note (to C++ and Java fans): |
|
78 such upQueries are only possible, if the exception handling mechanism |
|
79 does not automatically unwind the stack for the handler invokation. |
|
80 Since the handler must be able to proceed the execution and return |
|
81 a value to the raiser .... |
|
82 |
61 |
83 |
62 [see also:] |
84 [see also:] |
63 Signal SignalSet Exception |
85 Signal SignalSet Exception |
64 Object |
86 Object |
65 (``Exception handling and signals'': programming/exceptions.html) |
87 (``Exception handling and signals'': programming/exceptions.html) |