Symbian OS Getting Started Guide-error handling and cleaning

Abstract: Error Handling and cleanup are particularly important for the development in the Symbian OS environment. In fact, error handle is used to compile more reliable programs, and cleanup framework is the basis of Symbian OS programming, make sure that error handling and cleaning are efficient and easy to implement.

OOM (out-of-memory) errors have to be discussed in the Symbian OS environment. The current desktop memory capacity is getting bigger and bigger, and the virtual memory created on a larger hard disk may be restarted frequently. In this case, memory depletion rarely occurs. In the Symbian OS environment, Ram is less than 4 MB, and generally does not exceed 16 Mb. You do not need to restart the system during use. Therefore, we should pay attention to the following issues during the development in the Symbian OS environment:

Efficient programming is required so that the program does not waste Ram.
Resources must be released as soon as possible, because it is impossible to release resources, so that running programs consume more and more RAM.
You must handle out-of-memory errors. In Symbian OS, such errors can occur randomly.
If the memory is insufficient, some operations are stopped and user data cannot be lost.
If the memory is insufficient during an operation to allocate several resources, you must clear all these resources.

In fact, the Symbian OS error handling and clearing framework is not only valid for OOM errors. Many other operations may fail due to their environmental conditions, such as reading and writing files and opening files, send and receive data in a communication session. You can also use the error handling and clearing framework.

The following are some tools used to handle out-of-memory errors and test OOM:

The most common debugging key
Commonly used CTRL + ALT + Shift + (A uses heap unit, B file server resources, and C window server resources)
Heap check tool used to check whether the resources allocated by the function are released
C ++ destructor to destroy objects
Heap failure tool intentionally produces an error
Indicates an error. One of the basic functions is user: Leave ()
Clear Stack
Exception capture device: Uses traps to capture abnormal exit processes, similar to the try-catch mechanism in C ++.
Cbase class, the base class of all c classes, identified by clearing the stack, contains a C ++ destructor
Two-phase Constructor
Naming Conventions

The tool described above will be described in the following sections:
Heap check:
Macro _ uheap_mark and _ uheap_markend are mainly used.
Macro _ uheap_markend is mainly called in the destructor. If macro _ uheap_mark is included in any position in the program, you can check whether the heap operations in the middle are balanced, that is to say, if the number of heap units is different from the number of call _ uheap_mark, an error occurs in the program.
Destructor
I think everyone is familiar, just to mention it briefly
Not all objects used in the program must be released in the destructor. Only the objects owned by the program are destroyed, and temporary local variables are not included.
Heap failure Tool
This tool is mainly used to handle out-of-memory errors. An application named memorymagic serves this purpose, but not all Symbian systems have corresponding applications.
For more information, see the official Symbian website.
Abnormal exit mechanism
Of course, user: Leave () is used to exit abnormally based on different error codes (refer to the Symbian error codes in this blog). The user: Leave () function can terminate the operation of the active function, and terminate all the called functions.
Clear Stack
Stack cleanup solves the following problems: the stack is allocated on the stack, but the unique pointer to it is the object of automatic variables. If the function of the assigned Object exits unexpectedly, you need to clear the object. Routine
Case emagiccmd:
{
CX * x = new (eleave) CX;
Cleanupstack: pushl (X );
X-> usel ();
Cleanupstack: popanddestroy (X );
}
The program can exit normally regardless of whether usel () runs abnormally, because as part of exception handling, it is necessary to pop up and destroy all objects on the stack. You can do the same.
Case emagiccmd:
{
CX * x = new (eleave) CX;
Trapd (error, X-> usel ());
If (error)
{Delete X;
User: Leave (error );
}
Delete X;
}

Note: There is no need to clear stacks.
We only need to clear the stack to prevent the Destructor from traversing the object. If the destructor of this object will be called, we must not clear the stack.
Generally, the member variables of a class can be destroyed by the class's own destructor. Therefore, you should never push the member variables into the cleanup stack to avoid secondary deletion!

Two-Phase Structure
Stack cleanup is used to save the pointer to the heap-based object so that cleanup can be performed when an exception exits. This means that you must have the opportunity to push the object into the cleanup stack. This problem can be solved using a two-phase structure.

First, remember that the C ++ constructor should not contain any function that may exit unexpectedly. Routine:
Class Cy: Public cbase
{
Public:
Cy ();
~ Cy ();
Public:
CX * IX;
Cy: cy ()
{
IX = new (eleave) CX;
}
Cy :~ Cy ()
{
Delete IX;
}
}
Call
Cy * Y = new (eleave) Cy;
Cleanupstack: pushl (y );
...
Cleanupstack: popanddestroy (y );
In this case, a CX is allocated during the Cy allocation process. Since the constructor cy () does not have an exception handling mechanism, once the allocation of Cx fails, the memory leakage error is returned, therefore, we need to use a completely independent function to implement this. Therefore, constructl () is defined ()
Class Cy: Public cbase
{
Public:
~ Cy ();
Static Cy * newl ();
Static Cy * newlc ();
Void constructl ();
Public:
CX * IX;
Cy :~ Cy ()
{
Delete IX;
}
}

Void Cy: constructl ()
{
IX = new (eleave) CX;
}
The call is changed:
Cy * Y = new (eleave) Cy;
Cleanupstack: pushl (y );
Y-> constructl ();
...
Cleanupstack: popanddestroy (y );
It is clear that constructl () can be safely cleaned.

Some experience sections:
Objects cannot be assigned twice or deleted twice.
Delete Ib; // Add
IB = NULL; // Add
IB = new CB;
Do not delete non-owned objects
You must never exit abnormally from the C ++ constructor.
Use naming conventions to help you understand programs.
Clear stacks properly.
Use the macro trapd () with the user: Leave ().
-----------------------------------------------------------
In short, the error handling and cleaning in Symbian OS are extremely complicated and difficult to understand. We can only overcome the problem with patience and patience.

-- Feng Xiaoyun original