Design for Error Handling
Michael Elizabeth Chastain
<mec@duracef.shout.net>
Tue 14 Nov 1995

Copyright 1995 Michael Chastain
Licensed under the Gnu Public License, Version 2



=== Error Types

    ErAbort	An internal programming error
    ErFatal	An external call failed and prevents further execution
    ErMem	Out of memory
    ErPtr	Zero pointer
    ErRange	Index out of range
    ErUser	User input failed and prevents further execution

Examples of 'ErAbort' are 'bad enum' and 'bad state'.  An abort
indicates that the program's internal model has a bug or has been
corrupted.

Examples of 'ErFatal' are 'failed ptrace' and 'failed read'.  The model
expects something and cannot get it.  The model is still intact, but the
program cannot continue after this failure.

'ErMem' is caused by memory exhaustion.  It's a separate case because I
expect some C++ language facilities to be unusable when this happens,
and because the user can treat this condition differently.

An 'ErPtr' is a zero pointer, and an 'ErRange' is an index out of range.
These are both forms of 'abort'.

Example of 'ErUser' is 'input file not found'.  This has the same
consequences; the program cannot continue.  But in this case, the user
is responsible for fixing the broken input.

Many things, such as 'unknown system call', are not errors at all.
These are legal behaviour for the target process and they are part of
the model of what a target process can do.  They will always trace, but
may lead to 'ErUser' when replayed.



=== What you should do

ErAbort, ErPtr, ErRange

    Report the error as a bug in the program.

ErFatal

    Check for resource exhaustion (such as no more processes or no more
    disk space).  If this isn't the problem, report the error as a bug
    in the program.

ErMem

    Increase available memory.  Either run fewer competing programs on
    your system, or increase the amount of swap space.

ErUser

    Fix the reported problem and run again.
