Shareware Overload/ShartewareOverload.cdr/progm/funkybox.zip/GOBANANA.DOC

Text File | 1983-04-01 | 12KB | 236 lines

***********************
  ON ERROR GO Bananas
***********************

PEOPLE SYSTEMS, LTD. -- SOFTWARE
Copyright 1983 (c) L. A. Warner

A short tutorial on error trapping and debugging in BASIC. It could
be a fat book if we tried to review the whole subject, but that is not
the intention of this program. We will try to make some sense out
of the lack of priority in the manuals, and put some perspective
on the subject, for those who are not too familiar with it. For a
definition let us say that the purpose of ERROR handling routines is
to catch the error and provide a means of handling it and keep the
program running, instead of shutting down when an error message is
displayed. This is the purpose of error trapping in professional
software.

DEBUGGING  VS.  ERROR TRAPPING
First, let us separate DEBUGGING from ERROR handling so that we can
discuss them independently. Although there is a considerable
overlap, DEBUGGING a program is quite different from trapping run-
time errors in a well debugged program. Or saying it in another way,
ERROR TRAPPING routines should be kept out of a program until the
program has been well planned and executed, and thoroughly debugged.
Don't trap errors if you can conveniently eliminate them.

All program proceedures should be designed to eliminate errors in
keyboard inputs, and in peripheral operations, as well as the expected
program integrity for its intended purposes. There are many examples
in the manuals of how to extract the correct inputs and interfaces
with peripherals. The more experience playing ~what if~ a pro-
grammer has, the better he gets at DEBUGGING. We'll talk about
DEBUGGING in another article in the series.

LONG PROGRAMS
Let us also eliminate the short programs that we play with for learn-
ing purposes from our consideration. This article is aimed at the big
program that takes 2 -3K or more of disk storage. The principles apply
to the small ones, but their problems are much clearer and easier to
isolate. In fact, one ON ERROR GOTO routine may be all that's needed
for a short program. However, we will recommend ERROR
trapping routines be sectionalized in various parts of  big pro-
grams, instead of trying to write one humongous ON ERROR GOTO
catch-all that can cause all kinds of interactive problems, that may
unravel at the speed of light if stirred up, like a hornet's nest.

Let us assume we have a well debugged program, and we want to keep
the possible peripheral and keyboard errors from causing an error
message that shuts down the program and loses all the work.
For example, one of the common errors to protect against
is the problem of keyboard inputs that name a file to OPEN it.

FILE NAME ERRORS
Even with a protected input subroutine for keyboard (see VOL 2.0) an
operator can enter a name that is correct but just one letter short and
the CPU will issue an error message like File not found and shut down
with it's quizzical ~OK~. And you know the users are going to sit there
wondering what to do now. An error trapping routine is needed
that lets the operator have another chance to ~TRY AGAIN~ while looking
at the incorrect input string and if possible, the directory of FILES.

TRY AGAIN - VIEW THE PREVIOUS ERROR AND FILES ROUTINE
A simple way to show FILES and encourage correct FILEname type-in.

100 PRINT "PERHAPS YOU WOULD LIKE TO SEE THE FILEnames?"
110 PRINT "LOOK AT THE BOTTOM OF THE LIST FOR THE NAME"
120 PRINT
130 FILES  '**** prints out on screen list of FILEnames ****
140 PRINT
150 PRINT "NOW ENTER THE NAME CAREFULLY"
160 PRINT "TYPE IT THEN ENTER,  EXACTLY AS SHOWN"
170 PRINT
180 ON ERROR GOTO 1000   'error trap in place before input
190 GOSUB 20000              'controlled input routine ( see Vol 2.0 )
200 REM                      'returns WORD$
210 NAME1$ = WORD$           'assigns WORD$ to a $ and saves it
220 OPEN WORD$ FOR INPUT AS #1   'opens NAMEfile for input to program
230 FOR Z = 1 TO 15: INPUT #1, LK1$(Z),DLK1$(Z) : NEXT
240 PRINT    'line above reads disk into arrays LK1$, DLK1$
250 ON ERROR GOTO 0   'turns off the ERROR trapping
260 PRINT "GOOD SHOW -- THAT WAS FINE !" 'read-in completed
*
*
*
999 GOTO XXXX  'this bypasses the ERROR routine following
1000 PRINT " PLEASE, TRY AGAIN ":BEEP : RESUME 170
REM     'simple error routine returns to do it again - don't CLS
*

STUDY THE ERROR MESSAGES
Try this in BASIC-direct mode -  ENTER   ERROR n  -- see the messages.
Of course, IBM-PC Error Messages are shown in Appendix A, but there
are some errors that are unprintable (31-49). Did you know, the pro-
grammer can create his own error routines and messages by using num-
bers above 200 (See ERROR n  --  page 4-80 in BASIC). IBM-PC's BASIC
is very extensive and error trapping is well supported and elegant.

IBM-PC ROM IS WHERE IT'S AT.
It's all in the 40 K of super ROM that demonstrates IBM's expertise.
Although there have been few articles written on the subject,
I'm sure you're aware that it's IBM's effective ROM and ERROR trapping
and the extended BASIC that makes a programmer's life pleasant. Reviews
comparing RAM sizes and drive capacities and plug-in slots don't
mean much. But DOS, ROM and the elegant BASIC is where IBM-PC's at.

VARIOUS TYPES OF USERS
There are at least three classes of users or operators that must be
considered by the programmer. The highest class of user is the
technical operator, someone of the quality and accuracy of a program-
mer, who can operate the CPU and make sense out of an ERROR and
probably wouldn't make the same mistake twice. This is a special type
and should not be expected except in high tech software programs. And
the high tech will probably turn it over to his secretary after he gets
tired of playing with it, anyway.

Next in line of decreasing qualification is the secretary who will be
using the program regularly and will develop a facility for operating
it without too many problems, but she is always being interrupted by
the phone and can not stay at the program for long periods, so she
needs especially clear instructions and prompts at every step.

THE YOUNGSTER IN THE ARCADE
Now, at the other end of the qualification spectrum we have the young
game player, who will, when things get boring, test the programming to
see how he can make it mess-up, if possible. Or the neophyte that
doesn't pay attention to instructions the first or the second or the
third time, but expects to be bailed out whenever he gets into trouble.
Obviously, game debugging and ERROR planning is a specialty far beyond
the purview of this short article. Fool-proof programming isn't too
difficult but idiot proofing is almost impossible.

There may be many more types of users in between these extremes, but
of course. The programmer would do well to consider the possible
nature and quality of the users and plan accordingly. Is the user
under stress at an alarm system? Does the user understand a foreign
language better? Is he young, inexperienced or just having a good
time in an arcade or a tavern? Is it a sensitive subject or are the
users especially sensitive to the subject matter at this time?

So, decide the quality of the expected user and pattern your error and
debugging planning just a little bit more ~friendly~, if you like that
word, and you'll probably have few problems. But assume all users are
as careful and know as much about the program as you do, and you will
doubtless answer many long distance calls from irate consumers of your
products.

BANANA ROUTINES
On this disk there are several short routines that demonstrate some
of the options in ERROR handling. They all have BANANA n  for a title.
It would be useful to print these out and play with them for a while,
to get familiar with the process. Then come back and read the following
sections for further information.

Incidentally, having read them all thoroughly, one of the better
books on the IBM-PC is David Lien's  "Learning IBM Basic for the
Personal Computer" .It has a good introduction to ERROR handling. There
is also " A Guide to Programming -- IBM Personal Computer " by Bruce
Presley, that is also well worth owning. If you value your time, own
good reference books, and use them regularly.

TYPICAL ERROR HANDLING ROUTINE
Lets look at a typical ON ERROR handling routine :
                                (added after debugging)
90 REM --- there may have been programming preceding this point.
95 REM --- that didn't require error trapping and handling.
99 REM
100 REM --- program section requiring error routine follows
110 ON ERROR GOTO 1000  'on a small program this might be line 1
120 REM --- program section being trapped starts here
*
900 ON ERROR GOTO 0  ' turns off error trapping when not needed.
950 REM --- end of program section
*
999 GOTO 1200 :REM ---- protects against run-thru and hang-up
*
1000 IF ERR=25 OR ERR = 27 THEN PRINT "SORRY--PRINTER NOT READY":
            PRINT "PLEASE --PRESS RETURN WHEN READY" :INPUT ""; Z$:
            RESUME  0    ' resume at the statement causing error
1010 IF ERR=53 THEN PRINT "TRY THE NAME AGAIN, PLEASE":RESUME 170
*
1200 ON ERROR GOTO 2000  'error trapping for the next program section
1210 REM --- programming begins again

SUMMARY
Important factors that are worth repeating : ON ERROR GOTO line must
precede the error occuring in the program. The error handling routines
should be by-passed by GOTO or END avoiding infinite loops or crashes.
Turn off error trapping when not needed. The requirement for error
trapping is determined during debugging. Don't trap an error, correct
the programming to eliminate it, if possible. Keep the error messages
simple and polite, of course. Show the error to the operator, so it
can be corrected, run it by  so that the error can be observed.

Generally error routines will interfer with debugging if imposed early.
So dont put them into complex programs until debugging has determined
where they are required. For every good rule, there is usually also
a good exception that " im - proves " the rule. Yes, sometimes
debugging is helped with the proper error routine to keep from losing
input data from crashes. It might be better to SAVE it to a disk file
instead of confusing debugging with error handling. But in a complex
situation the use of ERL -- error line -- may assist you in debugging.

TYPES OF RESUME STATEMENTS
Study where you want the RESUME statement to take the program.
There are four options : omitting RESUME will restart the program at
the point the ON ERROR GOTO directed it. If there is no error handling
routine, it will continue from there. This may be useful for avoiding
a loop when the operator isn't familiar with the equipment. In fact a
counter C=C+1 with an IF THEN -- RESUME can test whether the
user can recover but after three tries the program proceeds,
perhaps without the printer or other peripheral, if at all possible.

The RESUME ### line should be carefully selected. Are you setting up a
loop, can the operator recover, if not is there a counter and an escape
route? Don't forget to initialize the counter or it wont work in
between RUNs. Of yes, we ought to remind you that RUN ### will
clear variables and arrays each time, but a GOTO will not, nor will it
reset a counter without the proper instruction, like C=0 in the right
place.

RESUME  or RESUME 0  returns the action to the statement that caused
error. Which says that in the meantime the error must have been cor-
rected or else a hang-up loop will begin. Do not use RESUME[0].
This unnecessary form RESUME[0] has scared lots of IBM-PC-ers away. It
really wasn't intended to be used in that form ( [] contain optional
data, remember). But IBM would have been better advised to omit [0].

RESUME NEXT is self explanatory, it will restart at the next STATEMENT
after the one causing the error, not the next LINE, so watch multiple
statement lines when using RESUME NEXT.

Happy Error Chasing -- You will find it's easy once you get into it.
Read the section on debugging, note how they overlap.