To help Symbian developers identify potential problems early in development, macros are provided to test for error conditions in functions (asserts) and objects (class invariants). Assertions are implemented using panics.
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.
Assertions
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
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.
Some types of error are due to bad program code, such as passing an illegal parameter value. When this type of error is discovered, the thread associated with the erroneous program should be terminated. On the Symbian platform, this is a referred to as a panic. The only proper response to a panic is to fix the program code.
Typically, a panic is not discovered by the program that made
the error, but by some library code which operates on behalf of that
program. If the library code is in a DLL running in the same thread
as the program, it calls User::Panic() to panic the
thread. If the library code is in a server executing on behalf of
another program, the server panics the client thread by calling RMessagePtr2::Panic(), where RMessagePtr2 is the handle to the message sent by the client to the server.
Panics are characterized by two pieces of information:
category - a string of up to sixteen characters, which defines the context of a panic.
panic number - a number that, in the context of a category, identifies the specific cause of the panic.
KERN-EXEC 3 — raised by an unhandled exception such as an access violation caused, for example, by dereferencing NULL or an invalid pointer.
E32USER-CBASE 46 — raised by the active scheduler as a result
of a stray signal. This could occur if you have forgotten to call
an active object's SetActive() method after making
an asynchronous request.
USER 11 — raised when an operation to modify a descriptor fails because the operation would cause the descriptor to exceed its maximum allocated length.