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.