Bug #515
Data handlers cannot deal with unexpected types
Status: | New | Start date: | 08/19/2011 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Specification | |||
Target version: | rsb-0.18 |
Description
See also: the first topic of Meetings2011-08-02.
Problem Statement¶
Associated handlers of listeners basically have to expect events with payloads of any type (unless a type filter is installed on the listener). This can be a problem for handler classes like DataHandler
or DataFunctionHandler
in C++ that can only handle events with certain payload type, because the behavior for events with incompatible payload types has not been specified yet.
- Clients may get the impression that handlers like
DataHandler
cause the associated listener to only receive events that have compatible payload types - This is currently not true; Instead, the program will most likely crashes due to an invalid
static_pointer_cast
Potential Solutions¶
Signal Errors for Incompatible Events¶
Classes like DataHandler
could signal an error when encountering incompatible payload types.
- Aborting the program
- Displaying an error message but continuing
- Configurable behavior
Drop Incompatible Events¶
DataHandler
and friends could check the payload types of events being dispatched to them and simply ignore events with incompatible payload types.
This would lead to inefficient processing if a single listener with multiple handlers for different payload types was used, since the dispatching mechanism would still dispatch all events to all handlers which would then drop unsuitable events only after most of the processing already happened.
General Considerations¶
Both previously mentioned solutions can be implemented in several different ways:- Introduce a common base class for
DataHandler
and friends that implements the chosen behavior (error or drop) in aprocessable
method:processable
would be called to determine whether an event should be dispatched to a handler- If
processable
returnedtrue
, the event would be dispatched in the usual way by callinghandle
- Integrate feedback from handlers into the dispatch logic
- Dispatching could display warnings or signal errors if events are dropped because they are not handled by any handler
- This could be achieved by adding a return value to
handle
or the above mentionedprocessable
method- The downside of a return value for
handle
would be potential confusion of clients implementing theHandler
interface
- The downside of a return value for
- It may be necessary for efficiency reasons to communicate information regarding the desired payload types of registered handlers all the way back to the transport layer
Related issues
Associated revisions
refs #515
- src/rsb/Handler.h: added class FilteringHandler
History
#1 Updated by S. Wrede about 13 years ago
- Target version set to rsb-0.7
#2 Updated by R. Haschke about 13 years ago
As third method to handle the problem, we also discussed with Jan to install a filter, which ignores non-matching events as early as possible. This would require a type-based routing of incoming events to appropriate listeners.
#3 Updated by J. Moringen over 12 years ago
- Target version changed from rsb-0.7 to rsb-0.9
#4 Updated by J. Moringen over 11 years ago
- Target version changed from rsb-0.9 to rsb-0.10
#5 Updated by J. Moringen almost 11 years ago
- Target version changed from rsb-0.10 to rsb-0.11
#6 Updated by R. Haschke about 10 years ago
With commit:5ee2b2c66 Jan implemented the required TypeFilter. In combination with FilteringHandler(TypeFilter, DataHandler/DataFunctionHandler) one can now ensure type safety.
If you don't vote for instantiating the TypeFilter by default as soon as one uses the DataHandler/DataFunctionHandler
(which of course wouldn't allow to handle differently typed events on a single Listener), you should add some docs in DataHandler+DataFunctionHandler pointing the programmer to the potential issue and its TypeFilter solution.
#7 Updated by J. Wienke almost 10 years ago
- Target version changed from rsb-0.11 to rsb-0.12
#8 Updated by J. Wienke over 9 years ago
- Target version changed from rsb-0.12 to rsb-0.13
#9 Updated by J. Moringen over 8 years ago
- Target version changed from rsb-0.13 to rsb-0.14
#10 Updated by J. Moringen over 8 years ago
- Target version changed from rsb-0.14 to rsb-0.15
#11 Updated by J. Moringen over 8 years ago
- Target version changed from rsb-0.15 to rsb-0.16
#12 Updated by J. Moringen over 7 years ago
- Target version changed from rsb-0.16 to rsb-0.17
#13 Updated by J. Moringen about 7 years ago
- Target version changed from rsb-0.17 to rsb-0.18