Symbian3/SDK/Source/GUID-40671EEC-DACC-5F0B-978C-2794FB206E62.dita
author Graeme Price <GRAEME.PRICE@NOKIA.COM>
Fri, 15 Oct 2010 14:32:18 +0100
changeset 15 307f4279f433
parent 0 89d6a7a84779
permissions -rw-r--r--
Initial contribution of the Adaptation Documentation.

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-40671EEC-DACC-5F0B-978C-2794FB206E62" xml:lang="en"><title>Types
of error and recovery</title><shortdesc>Describes error conditions and how errors are handled.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Error conditions can be divided into three broad categories:</p>
<ul>
<li id="GUID-5E06C730-C4DC-5E09-A7F1-8101BC8B6AFC"><p>program errors, such
as an attempt to access an element beyond the bounds of an array or buffer</p> </li>
<li id="GUID-DFCB0C57-A2BB-55DF-BA2A-FC0D5D3C9F45"><p>environment errors,
such as insufficient memory, insufficient disk space, or other missing resources</p> </li>
<li id="GUID-AD65EABD-573A-5A03-B59B-50A1DE7219DF"><p>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</p> </li>
</ul>
<p>Program errors are checked by asserts (<codeph>__ASSERT_DEBUG</codeph> macro),
and are signalled by a panic. Recovery from such errors involves re-writing
part of the program that contained the error. </p>
<p>Environment and user errors can be handled in broadly two ways:</p>
<ul>
<li id="GUID-7DAF8642-F413-5332-958C-A7B31C1BDD1F"><p>If they can be detected
before an action is performed, then a return value other than <codeph>KErrNone</codeph> is
a convenient means to signal the error.</p> <p>This method is simple to program,
and cleanup requirements, if they exist at all, are often easy to identify
and handle.</p> </li>
<li id="GUID-4561F90D-E7C0-5D5C-AB33-4F2C25D7C4F1"><p>Alternatively, the program
can use the exception handling and cleanup techniques discussed in this section.</p> <p>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.</p> </li>
</ul>
<p>When programming for possible environment or user error conditions, bear
in mind both approaches for handling them, and choose the most suitable one.</p>
<p>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. </p>
</conbody></concept>