66 lines
4.1 KiB
Prolog
66 lines
4.1 KiB
Prolog
A COMMENT ON ERROR TRAPS
|
||
By Nick Fotheringham
|
||
From The Apple Barrel, July'82
|
||
I.A.C.-TC
|
||
|
||
You have finally gotten all of the bugs out of that special program that has
|
||
kept you in seclusion for the past several weeks. It does exactly what you
|
||
want it to do, and you are ready to impress someone with it. You beg your boss
|
||
to take time from his busy schedule for a session with your Apple, and after
|
||
ten minutes of routine data entry, your program is nearing its flashy finale.
|
||
The next question appears: "How many sides on an octogon?" As your boss enters
|
||
"e..i..g...", you stifle, "Not that key, you dummy, the '8'". Too late... The
|
||
Apple has already responded with a "TYPE MISMATCH" message and shut your
|
||
program.
|
||
|
||
One purpose of an "error trap" or "error handling routine" is to help prevent
|
||
such embarrassing situations. Your Apple's BASIC interpreter already has
|
||
several built-in error traps which were designed to protect the system from
|
||
your unreasonable requests, such as attempts to divide by zero or to exceed to
|
||
system's capacity ("STRING TOO LONG", "OVERFLOW", "FORMULA TOO COMPLEX", "OUT
|
||
OF MEMORY"). Fortunately for many applications, these traps can be avoided by
|
||
using the ONERR GOTO.....POKE 216,0 commands. ONERR GOTO... disables the
|
||
system's internal error handling routine and, upon encountering an error,
|
||
transfers program processing to a statement defined by the GOTO statement,
|
||
typically a replacement error handling routine of your design. The POKE 216,0
|
||
command reinstates the system's error handling routine.
|
||
|
||
For many beginning programmers, disabling the system's error handling
|
||
routine, only to replace it with one that you must design and which uses some
|
||
of your precious RAM memory seems like lunacy. The major reason for doing so
|
||
is that most of the errors to which the system reacts need not be fatal to your
|
||
run. The computer views these errors as fatal because the contexts in which
|
||
they may occur are so diverse that the only general solution that ensures
|
||
protection to your computer is to terminate your run. However, within your
|
||
program the context within which an error may occur can often be much more
|
||
narrowly defined, and nonfatal solutions may be developed. Some of these
|
||
solutions are described below.
|
||
|
||
One of the most common applications for error traps is to guard your program
|
||
against typing errors during data entry from the keyboard. Most such errors
|
||
can be resolved without aborting your program by designing the program to
|
||
receive all input as a string variable, say A$. Because A$ will accept input
|
||
from nearly every key (except RESET) without a TYPE MISMATCH error, it is
|
||
preferable to A or A% as an input variable. You may then test the input to see
|
||
if a RETURN has been entered (A$=""), to see if a number has abeen entered
|
||
(ASC(A$)>47 AND ASC(A$)<58. If the desired numerical input has been entered,
|
||
you may then convert the input to its numerical equivalent (A=VAL(A$) or
|
||
A%=INT(VAL(A$))) and then test to see if this value is within the range that
|
||
you expected as an answer to your question (A%>0 AND A%<5).
|
||
|
||
One of the great advantages of owning your own computer system on which you
|
||
run programs interactively is that you can usually train the system to come
|
||
back to you for help when it has a complaint instead of just dying. When a
|
||
"fatal" problem is encountered, such as an attempt to divide by zero, an error
|
||
trap can be used to print an error message of your choosing and then give you
|
||
an opportunity to change the denominator to a non-zero number and continue the
|
||
calculation or to abort that program segment (e.g. return to the menu).
|
||
|
||
Good programs should never "crash". Even when they fail to complete the task
|
||
for which they were designed, they should reach a controlled ending which
|
||
provides a detailed description of what went wrong and an opportunity to fix it
|
||
before ending. Since most of us write programs with the expectation that
|
||
others will run them, we should get in the habit of using error traps
|
||
routinely, and we should insist on such programming style in the commercial
|
||
software we buy.
|
||
|