Symbian3/SDK/Source/GUID-1171C47F-D7F3-5A49-B191-DB6CB7C84DC8.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-1171C47F-D7F3-5A49-B191-DB6CB7C84DC8" xml:lang="en"><title>Where
to put trap harnesses?</title><shortdesc>Describes the criteria that should be taken into account when deciding
where to put a trap harness.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Trap harnesses can be nested. If a function leaves, control goes to the
most recent trap harness in the call stack. This allows independent sub-modules
to do their own exception handling. Effective trap programming requires that
the unit of recovery be correctly identified. </p>
<p>The most basic option is to rely on the top-level trap harness provided
as part of the application framework for all GUI programs. If a leave occurs,
and it is not handled by any explicitly coded harness, the framework displays
an error message corresponding to the leave code.</p>
<p>For some applications, the unit of recovery may be the processing of any
user command. In a particular application, the unit of recovery may be associated
with part of the processing of a particular command — a much finer-grain
approach.</p>
<p>Coding a coarse-grain unit of recovery has the advantage of only one trap
harness and recovery code, but the disadvantage that recovery code may be
general and complex, and the danger that a small error leads to catastrophic
results for a user (e.g. if not enough memory to apply bold formatting resulted
in termination of the word processor with loss of data!).</p>
<p>Coding too fine-grain units of recovery results in many trap harnesses,
lots of recovery code which may require individual attention in each case,
and potentially significantly increased code size.</p>
<p>The correct choice is application-specific. For large applications, there
may be a single course-grain unit of recovery, with other harnesses in particular
places. </p>
</conbody></concept>