General Error Handling
| Rule 60. Prefer compile-time errors over run-time errors. |
Of course it would be preferable to detect all possible errors at compile time once instead of running into them during program executing. Naturally this is not possible, but the strict type checking mechanisms of C++ help you to detect wrong usage of objects at compile time. This is an advantage of C++ over dynamic languages like Perl or PHP which do most of this checking at runtime.
| Rule 61. If a function can recover from an error, it must not return an error. |
When a function experiences an error but you know how this error can be corrected and how the function can recover and continue execution, then you should do so, as long as the semantics of the function do not change and no side effects occur.
For an example, consider the insertion method of a linked list of objects. When you try to insert an object that is already part of that linked list, the function should not return an error, but simply leave the list unchanged. In this example the insertion function was able to recover from an error, but the semantics did not change. The situation is different if you try to insert an object which is already part of another linked list - inserting this object would imply the removal of the same object from the other list. In this case a recovery would imply side effects which are to be avoided, so the function must return an error.
Kaya Memisoglu 2005-01-06
