Defensive programming

To help developers identify potential problems early in development, macros are provided to test for error conditions in functions (asserts) and objects (class invariants).

Casting is one well known source of hard-to-find errors. Casting discusses its use.

One method of catching errors early is to identify conditions that should be true at the beginning and end of functions, and raise errors if they are not.

Two mechanisms support this programming style.

• asserts

• class invariants

Two macros are supplied for asserting specific conditions in functions:

• __ASSERT_ALWAYS to catch run-time invalid input, for both release and debug builds

• __ASSERT_DEBUG to catch programming errors, for debug builds only

Class invariants are used to test that an object is in a valid state. They are used only in debug builds.

• Define class invariants for non-trivial classes using __DECLARE_TEST. The class must supply functions that specify its allowed stable states.

• To ensures that the object is in a stable state prior to executing the function, call the invariant at the start of all public functions using __TEST_INVARIANT.

• For non-const functions, you can ensure that the object has been left in a stable state by also calling the invariant at the end of the function.

Casts, as in other operating systems, should be used with caution. If a cast seems to be needed, check that this does not reflect a design weakness.

The C++ dynamic_cast operator should not be used because Symbian OS does not use C++ exceptions in user code.

Note that in early versions of the OS (pre v6.0), the GCC compiler did not support the C++ casting operators. The idiom was then to use instead one of the macros REINTERPRET_CAST, STATIC_CAST, CONST_CAST, and MUTABLE_CAST, which were defined as simple C style casts for that compiler.