Describes error conditions and how errors are handled.
Error conditions can be divided into three broad categories:
program errors, such as an attempt to access an element beyond the bounds of an array or buffer
environment errors, such as insufficient memory, insufficient disk space, or other missing resources
user errors, such as an attempt to enter bad data in a dialog, an invalid action in, say, a word processor, or bad syntax in a source file
Program errors are checked by asserts (__ASSERT_DEBUG macro), and are signalled by a panic. Recovery from such errors involves re-writing part of the program that contained the error.
Environment and user errors can be handled in broadly two ways:
If they can be detected before an action is performed, then a return value other than KErrNone is a convenient means to signal the error.
This method is simple to program, and cleanup requirements, if they exist at all, are often easy to identify and handle.
Alternatively, the program can use the exception handling and cleanup techniques discussed in this section.
This method is more appropriate when the detection of an error occurs deep inside the processing of a requested action: if the error return value method were used, every function would have to return such an error and cleanup requirements would have to be handled for virtually every function call. The logic becomes repetitive and it’s easier to incorporate it into an exception-handling scheme.
When programming for possible environment or user error conditions, bear in mind both approaches for handling them, and choose the most suitable one.
Applications must perform proper cleanup when an exception occurs, because they are designed to run for long periods (months or even years) without interruption or system re-boot.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.