ON ERR Programming

A person whom I’d never heard of sent me a cassette, saying that it contained an important program that “hangs up every time it is loaded”. I loaded the program and sure enough it did hang up. A touch of the NMI button on the Oliger DOS board gave me “O.K” at the screen bottom. Then LIST put the listing on screen where I discovered <ON ERR CONTINUE> in the first program line. I EDITed the line and removed the ON ERR, then found a subscript error in a following program line. The moral of this story is that if you use <ON ERR CONTINUE> you’d better have every conceivable error eliminated. I returned the cassette with the ON ERR removed and the program re-saved, with expanations, never to hear from my pen pal again: no thanks, no nuttings. AND, I paid the postage. The morale of that story is, if you ask someone to do something for you and he does it, you should thank him.

The TS-2068 “Remembers ON ERR” and the line number in an ON ERR statement “well after” the program line that contains the <ON ERR GO TO> statement has been executed. Then the first error condition forces the abandonment of sequential line read, and the line that is designated in the ON ERR statement is executed. Therefore, if you use <ON ERR GO TO line>, it is best to terminate the ON ERR “whether an error exists or not”. One DOS (AERCO FD-68) will carry forward a ON ERR condition when a new Basic Program is loaded without a computer reset. This can cause the next program loaded to give you an unpleasant suprise.

ON ERR programming can let the programmer do many things that cannot be achieved by any other means. But it is not good programming technique to leave a ON ERR condition dangling. I’ll give a couple of examples that can be modified and used in different ways. First, the cure for the FD-68 programs that may be loaded during a ON ERR condition in a preceeding program.

   5 REM ** RESET a ON ERR
  10 ON ERR GO TO 9000: STOP
  20 STOP : REM **Line to begin your programming.
9000 ON ERR RESET : GO TO 20

Let your auto run line be line 10. The ON ERR changes any existing ON ERR programming to line 9000, and then the STOP forces line 9000 to execute, where the ON ERR is cleared with RESET. Then your first real programming can begin at line 20.

The next illustration is more complex. Here we use ON ERR almost as we would use <IF THEN>. Say you need to present on screen the “status of a data base” contained in a character array “O$()”. A subscript error would occur if O$ were not dimensioned. Then you may want to know the actual Dimension of O$ array. Then you may also want to know the last “cell of O$” that contains data (not empty spaces). We will use ON ERR within counters to do that in the following subroutine.

   5 REM ** Use ON ERR to find the Dimension of a CHR$ Array.
  10 LET a=500: FOR n=1 TO a: ON ERR GO TO 9000: LET b=LEN o$(n) : NEXT n
  20 CLS : STOP : REM **Line to begin your Basic programming.
9000 ON ERR RESET : IF n<2 THEN PRINT "O$ is not Dimensioned."
9005 IF n>2 THEN PRINT "The Dimension of O$ is&gt; "; FLASH 1;"O$(";n-1;")"''
9010 IF n>1 THEN FOR n=1 TO n-1: ON ERR GO TO 9020: IF O$(n)(1)=" " THEN STOP
9015 NEXT n
9020 ON ERR RESET : IF n=1 THEN PRINT "O$ has no data": STOP
9025 ON ERR RESET : IF n>1 THEN PRINT "The last cell of O$ that has Data is "; FLASH 1;"O$(";n-1;")"
9030 BEEP 3,16: LET n=a: GO TO 20

Each of this routine’s actions to check the status of O$ serves the same purpose as an <IF THEN>, except that <IF THEN> cannot be used because it could result in a subscript error. So ON ERR allows us to check the status of a data base “whether the data base exists or not”. It is important to note that at the end of the <ON ERR> Subroutine, the <ON ERR> condition is cleared (RESET). Then any subsequent error will be reported as normal with a “report code” at the screen bottom.

Lets do one more that is simpler. This time we will check the status of a simple string content (A$). A subscript error will occur if A$ has not been initialized in this example. <10 PRINT "The Data Base is "; LEN A$;" bytes">. The ON ERR routine would be:

  10 ON ERR GO TO 9000: PRINT "The Data Base is ";LEN a$;" bytes.": ON ERR GO TO 9010: STOP
  20 STOP : REM * The next line.
9000 ON ERR RESET : CLS : LET a$="": GO TO 10
9010 ON ERR RESET : GO TO 20

If A$ has not been initialized, the ON ERR trips to line 9000. But if A$ has data the LENgth of A$ is reported and the second ON ERR designates a new line to GO TO if an error exists. Then STOP triggers the GO TO 9010. In either case <ON ERR RESET> clears the ON ERR programming. It might be worth noting that <ON ERR RESET> clears the error condition.

But, <ON ERR RESET> is ignored if the error condition has already been cleared. There is no adverse effect if <ON ERR RESET> is encountered. The follow on programming in the line is executed whether or not the RESET actually reset an error or not.

---

Notes

1. Line 9005 as printed tests IF n>2, and line 9000 tests IF n<2. An array dimensioned to a single element raises its subscript error on the second pass of the loop at line 10, so the subroutine is entered with n=2 and neither test is satisfied — that one case reports neither “not Dimensioned” nor a dimension. IF n>=2 at 9005 would close the gap. Reproduced as printed, because nothing else in the article establishes the intended form.