Bug #515

Data handlers cannot deal with unexpected types

Added by J. Moringen over 9 years ago. Updated over 3 years ago.

Status:NewStart date:08/19/2011
Priority:NormalDue 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.

Problems of the current implementation (restricted to C++ for clarity here):
  • 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.

Variations include
  • 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 a processable method:
    • processable would be called to determine whether an event should be dispatched to a handler
    • If processable returned true, the event would be dispatched in the usual way by calling handle
  • 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 mentioned processable method
      • The downside of a return value for handle would be potential confusion of clients implementing the Handler interface
  • 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

Related to Robotics Service Bus - Bug #1153: unknown data types cause crash when received Rejected 08/29/2012
Related to Robotics Service Bus - Enhancement #1515: Add data type to all participants, especially listeners New 05/27/2013
Blocks Compliant Control Architecture - Bug #973: Type filter for input ports New 03/28/2012

Associated revisions

Revision 568192cc
Added by J. Moringen over 8 years ago

Added FilteringHandler in src/rsb/Handler.h
refs #515
  • src/rsb/Handler.h: added class FilteringHandler

History

#1 Updated by S. Wrede over 9 years ago

  • Target version set to rsb-0.7

#2 Updated by R. Haschke over 9 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 8 years ago

  • Target version changed from rsb-0.7 to rsb-0.9

#4 Updated by J. Moringen almost 8 years ago

  • Target version changed from rsb-0.9 to rsb-0.10

#5 Updated by J. Moringen about 7 years ago

  • Target version changed from rsb-0.10 to rsb-0.11

#6 Updated by R. Haschke over 6 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 about 6 years ago

  • Target version changed from rsb-0.11 to rsb-0.12

#8 Updated by J. Wienke over 5 years ago

  • Target version changed from rsb-0.12 to rsb-0.13

#9 Updated by J. Moringen almost 5 years ago

  • Target version changed from rsb-0.13 to rsb-0.14

#10 Updated by J. Moringen over 4 years ago

  • Target version changed from rsb-0.14 to rsb-0.15

#11 Updated by J. Moringen over 4 years ago

  • Target version changed from rsb-0.15 to rsb-0.16

#12 Updated by J. Moringen almost 4 years ago

  • Target version changed from rsb-0.16 to rsb-0.17

#13 Updated by J. Moringen over 3 years ago

  • Target version changed from rsb-0.17 to rsb-0.18

Also available in: Atom PDF