CodingGuidelines » History » Version 1
J. Wienke, 05/16/2011 12:09 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 | 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. |
7 | 1 | J. Wienke | ** If multiple inheritance is feasible, use it to reuse the existing language exception types. |
8 | 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) |
9 | 1 | J. Wienke | |
10 | 1 | J. Wienke | h3. Barricade Strategy |
11 | 1 | J. Wienke | |
12 | 1 | J. Wienke | * Generally user-induced data should be validated on the client level. |
13 | 1 | J. Wienke | * Exception to this rule is the converter mechanism -> user data member of the event class |
14 | 1 | J. Wienke | ** Generally performing a validation already in client-level code is too expensive |
15 | 1 | J. Wienke | ** OutRoute: |
16 | 1 | J. Wienke | *** Always using exceptions in the sending stack is not possible for asynchronous sending strategies. |
17 | 1 | J. Wienke | *** An invalid combination of data and converter is a (user-induced) fatal error |
18 | 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) |