CodingGuidelines » History » Version 6
J. Wienke, 05/16/2011 01:25 PM
| 1 | 1 | J. Wienke | h1. Coding Guidelines |
|---|---|---|---|
| 2 | 1 | J. Wienke | |
| 3 | 1 | J. Wienke | h2. Error Handling / Exceptions |
| 4 | 1 | J. Wienke | |
| 5 | 1 | J. Wienke | * Use a common rsb::Exception for all exceptions |
| 6 | 4 | J. Wienke | * Rationale: Provides in the client application a way to handle all error from the communication layer uniquely |
| 7 | 1 | J. Wienke | ** 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. |
| 8 | 1 | J. Wienke | ** If multiple inheritance is feasible, use it to reuse the existing language exception types. |
| 9 | 1 | J. Wienke | * 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) |
| 10 | 1 | J. Wienke | |
| 11 | 1 | J. Wienke | h3. Barricade Strategy |
| 12 | 1 | J. Wienke | |
| 13 | 6 | J. Wienke | Generally: invalid data must not enter the backends |
| 14 | 6 | J. Wienke | |
| 15 | 1 | J. Wienke | * Generally user-induced data should be validated on the client level. |
| 16 | 6 | J. Wienke | ** Invalid data causes exception for the user |
| 17 | 1 | J. Wienke | * Exception to this rule is the converter mechanism -> user data member of the event class |
| 18 | 1 | J. Wienke | ** Generally performing a validation already in client-level code is too expensive |
| 19 | 1 | J. Wienke | ** OutRoute: |
| 20 | 1 | J. Wienke | *** Always using exceptions in the sending stack is not possible for asynchronous sending strategies. |
| 21 | 1 | J. Wienke | *** An invalid combination of data and converter is a (user-induced) fatal error |
| 22 | 1 | J. Wienke | *** 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) |
| 23 | 2 | J. Wienke | ** InRoute: |
| 24 | 2 | J. Wienke | *** two cases: |
| 25 | 2 | J. Wienke | ***# no converter available: |
| 26 | 2 | J. Wienke | ***#* Could happen because the receiver is not the cause of the message |
| 27 | 2 | J. Wienke | ***#* for Reader (pull-based model) an exception is possible without any problems |
| 28 | 2 | J. Wienke | ***#* Asynchronous case requires user checking for exceptions: |
| 29 | 2 | J. Wienke | ***#** Special event or tag in event for error condition |
| 30 | 2 | J. Wienke | ***#** A method for the user to check whether the event is an error condition or not |
| 31 | 3 | J. Wienke | ***# Error while converting |
| 32 | 5 | J. Wienke | ***#* Could be possible with UNRELIABLE communication that can cause damaged packages |
| 33 | 5 | J. Wienke | ***#* For RELIABLE use the same mechanisms as above |
| 34 | 5 | J. Wienke | ***#* For UNRELIABLE (in a first iteration) only log the error and do not dispatch to the user |
| 35 | 6 | J. Wienke | * ParticipantConfig: |
| 36 | 6 | J. Wienke | ** Data holder |
| 37 | 6 | J. Wienke | ** Validation performed by factory (first recipient of user-provided data) |