💾 Archived View for mirrors.apple2.org.za › archive › www.textfiles.com › apple › errors.txt captured on 2024-08-19 at 03:23:29.

View Raw

More Information

⬅️ Previous capture (2023-03-20)

-=-=-=-=-=-=-

2

---------------------------------------
[Ctrl-S pauses/Space=quit]

2
0

                    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.


---------------------------------------

Enter (1-10, M=Menu, Q=Quit) :