CodingGuidelines » History » Version 3
Version 2 (J. Wienke, 05/16/2011 12:23 PM) → Version 3/7 (J. Wienke, 05/16/2011 01:12 PM)
h1. Coding Guidelines
h2. Error Handling / Exceptions
* Use a common rsb::Exception for all exceptions
** 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)
h3. Barricade Strategy
* Generally user-induced data should be validated on the client level.
* 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:
***# 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
***# Error while converting
h2. Error Handling / Exceptions
* Use a common rsb::Exception for all exceptions
** 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)
h3. Barricade Strategy
* Generally user-induced data should be validated on the client level.
* 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:
***# 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
***# Error while converting