History

Coding Guidelines

Error Handling / Exceptions

  • Use a common rsb::Exception for all exceptions
  • Rationale: Provides in the client application a way to handle all error from the communication layer uniquely
    • In languages where multiple inheritance is a pain, this class inherits from a runtime-like error and a custom exception tree with e.g. InvalidArgument is created underneath this root exception type.
    • If multiple inheritance is feasible, use it to reuse the existing language exception types.
  • in C++, don't use exceptions in constructors if you have objects that need a manual deallocation (to be verified that the destructor is not called for half-constructed instances)

Barricade Strategy

Generally: invalid data must not enter the backends

  • Generally user-induced data should be validated on the client level.
    • Invalid data causes exception for the user
  • Exception to this rule is the converter mechanism -> user data member of the event class
    • Generally performing a validation already in client-level code is too expensive
    • OutRoute:
      • Always using exceptions in the sending stack is not possible for asynchronous sending strategies.
      • An invalid combination of data and converter is a (user-induced) fatal error
      • exit the program (using a macro/function that creates a segfault in any case to get a backtrace, assert could be switched off and the error would be unnoticed or untraceable)
    • InRoute:
      • two cases:
        1. no converter available:
          • Could happen because the receiver is not the cause of the message
          • for Reader (pull-based model) an exception is possible without any problems
          • Asynchronous case requires user checking for exceptions:
            • Special event or tag in event for error condition
            • A method for the user to check whether the event is an error condition or not
        2. Error while converting
          • Could be possible with UNRELIABLE communication that can cause damaged packages
          • For RELIABLE use the same mechanisms as above
          • For UNRELIABLE (in a first iteration) only log the error and do not dispatch to the user
  • ParticipantConfig:
    • Data holder
    • Validation performed by factory (first recipient of user-provided data)
  • Connection errors:
    • Should be noticeable every time
    • UNRELIABLE: errors could be ignored without violating QoS
      • InRoute: use (another) special error event
      • OutRoute: Reject sending (exception in user call to send) as soon as connection loss is noticed (no further guarantees for already submitted messages)
    • RELIABLE: first guess terminate the program because QoS is violated