73 lines
4.2 KiB
Erlang
73 lines
4.2 KiB
Erlang
---------------------------------------
|
||
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.
|
||
---------------------------------------
|
||
|