Are we supposed to use multiple instances of ON ERROR?
I'm confused about how Liberty Basic searches for this in the code. Here is the example in the help file:
on error goto [errorHandler] open "sillyfilename.txt" for input as #f close #f end
[errorHandler] print "Error string is " + chr$(34) + Err$ + chr$(34) print "Error number is ";Err end I'm confused because "on error" is above the line of code where the error is going to happen. Does Liberty Basic search backwards from the point of the error to find the on error statement?
My understanding is that on error creates a pending event just like the timer statement. So when the timer ticks or when an error occurs the code is sent to the handler. Just like the timer you should set and reset the on error handler, on error blank should reset the handler. If you leave it pending other errors may deflect your code to inappropriate handlers. On error [expectederror] would set it to what you next expect to go wrong.
I am more familiar with oncomerror which behaves this way.
To have greater control of errors, try something like this:
call openFile$ "input.txt", "#1" 'something that might return an error
sub openFile$ file$, handle$, mode on error goto [error] if mode then open file$ for input as #handle$ if not(mode) then open file$ for output as #handle$ exit sub [error] print "Something went wrong while opening '"+file$+"'" exit sub end sub
So basically, encapsulate code which may cause an error in a subroutine with its own "on error goto [error]" label.
you should set and reset the on error handler, on error blank should reset the handler
I'm afraid there no way to reset error handler Prove me wrong, please on error goto [err] print 1 print 1/0 'supposed to be handled by err handler [nxt1] if BeenHere>1 then end on error goto 0 print 2 print 1/0 'supposed to error (Div by Zero) and stop 'instead errs "key is missing" end
I have a program that opens an ini file and reads the file. This occurs at the very beginning of the program. If the ini file has been updated by me in a program update, there will be more entries than are in the customers ini file. So there will be an error reading the ini file because it ran out of data so there is an on error section that fixes it. Then after the main window of the program opens, there is another on error statement that catches like things like divide by zero etc.
It works the way I wanted it so you can reset the on error handler. In fact I posted this tid bit back on the old forum
Post by Brandon Parker on Oct 2, 2019 21:02:39 GMT -5
When possible, one should use error handlers in Subs/ Functions to trap and handle errors within those Subs/ Functions. When an error handler is activated in a Sub/ Function and properly dealt with, an LB program can resume normal operation since the error was handled with the Sub/ Function, and when that Sub/ Function exits the handler is pretty much destroyed along with the Sub/ Function. Handling errors at the deepest point of the stack will allow for most programs to recover in an easier manner. That being said, not all errors will be trapped by error handlers; the dreaded "Protection Violation" is one that will always cause an LB program to cease execution. Another "interesting" thing is that you can step through the LB Debugger and watch some errors occur, be trapped, and dealt with (like the divide by zero error) while other errors like an array index out of bounds will halt the LB Debugger even though the LB Runtime Engine handles that error fine as long as it is trapped correctly.
Error handlers work by scope so, whichever error handler was declared last in the scope that the program is in will be called when an error occurs. Error handlers are however not like Timers; you cannot "zero" one out to cancel it as far as I am aware.
Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM