Describes the criteria that should be taken into account when deciding where to put a trap harness.
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.
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.
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.
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!).
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.
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.