Subject: XB Error Trapping

From: "epergrem" <[email-masked]>
Date: Sat, 01 Jan 2011 23:33:36 -0000

After a long absence from XB I put together a short program last night to do some batch file processing.

Unfortunately, I run into a file occasionally which causes the program to error.  I've tried ON ERROR, but because it returns to the offending statement, it hasn't helped. Briefly:

 980  IF EOF(1) THEN CLOSE #1 :: GOTO 1100
1000  LC=LC+1
1020  LINPUT #1:LN$
1040  PRINT #2:LN$
...

What occasionally happens is an error occurs in the LINPUT statement.  This is always at the very end of the file.  Which means there is likely an problem at the very end of the file.

I've tried a variation where I set EF$="Y" in the ON ERROR routine and the following code, but still it craps out as an error on line 1020.  I'm guessing that ON ERROR isn't returning to the IF, but to the LINPUT portion of the statement.

1000  EF$="N" :: LC=LC+1
1020  IF EF$="N" THEN LINPUT #1:LN$ :: GOTO 1040
1030  CLOSE #1 :: GOTO 1100
1040  PRINT #2:LN$
...

In assembly I can control the return, but in XB I'm not sure I have the ability.  I realize that stylistically I can combine statements, etc., but I've tried to keep the code simple to troubleshoot it.

Any recommendations on how to handle the file error in XB?

Thanks, Ernie

---

From: Insane Multitasker <[email-masked]>
Date: Sat, 1 Jan 2011 18:33:54 -0600

Ernie,
ON ERROR and its counter-part RETURN allow you to specify when and how to return.  The ON ERROR routine is similar to GOSUB in that you should resume program execution with a RETURN statement:  you may return to a line number, the same line, or the next statement.  (RETURN 1600, RETURN, RETURN NEXT)

100 on error 1600
110 !program start
*....code

1600 ! error trap
1610 CALL ERR(a,b,c,d) :: print "error encountered";a;b;c;d :: on error 1600:: return 110 

I often reset the error trap prior to resuming execution.  You could also reset it after return, but that requires you to 'know' where the error happened.  Using the parameters from CALL ERR allows for creative and complex error handling based on line number and error type. 

In your program, you might do something like:
100 ON ERROR 1600
980  IF EOF(1) THEN CLOSE #1 :: GOTO 1100
1000  LC=LC+1
1020  LINPUT #1:LN$
1040  PRINT #2:LN$
1100 !io complete
1599 !error trap
1600 CALL ERR(A,B,C,D):: IF A=130 THEN PRINT "ERROR in file#";B::IF EOF(B)<>0 THEN CLOSE #B
1605 ON ERROR 1600
1610 IF D=1020 then RETURN 1100 ELSE RETURN  !RETURN NEXT would jump to the next statement)

The error trap checks for file IO (A=130) and if true, tells you the file number that caused the error. It then checks the file IO status and if the file is still open, attempts to close it.  This could result in a secondary error that won't be trapped unless you make the routine more complex.  In line 1610 we test the line number that generated the error and if it was 1020, we return to 1100 else we retry the line. 

Line 1605 resets the error trap so that the next error is trapped. This is important if you wish to retry the same line or next statement error, since you usually cannot know when to insert another ON ERROR statement in your code.

Lastly, I recommend reviewing the XB manual.  That and some experimentation should give you a great foundation for error control. In case you are curious, I used these techniques in my BBS code ;)

PS - You can have multiple error trap subroutines for various parts of your program but only one active on error line number at a time. 

> To: [email-masked]
> From: [email-masked]
> Date: Sat, 1 Jan 2011 23:33:36 +0000
> Subject: [TI994A] XB Error Trapping
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

---

From: "epergrem" <[email-masked]>
Date: Sun, 02 Jan 2011 00:49:40 -0000

Excellent!  Just what I needed. I guess that I missed that part about returning to any line number. :-)

--- In [email-masked], Insane Multitasker <insane_m@...> wrote:
> > From: epergrem@...