Author Topic: ON ERROR RESUME_RETURN bug (Read 3374 times)

TempodiBasic · « **on:** September 12, 2021, 02:04:08 pm »

Hi Boys and girls of QB64

thanks to Pete for his code that I have hugely modded to show the bug
thanks to vwbugsguy (on QB64 discord server) to show accidentaly this bug

copy paste and run this code...

Code: QB64: [Select]

On Error GoTo errhandler
 
Locate -1, -1
Print "This routine is buggy!"
 
End
 
errhandler:
Print Err
Resume Next
Return
 

what do you observ? That it runs well showing error code and then continuing its flow to the end of program!
[ You are not allowed to view this attachment ]
ok, but why can I type RETURN statement that it is for closing the GOSUB subroutine at the end of error trap subroutine?
Why for parser and compiler it is ok? Is it right that the error trap subroutine has its end in the RESUME [NEXT] statement, isn't it?
So for now it is possible to close an Error trap subroutine using RETURN

Code: QB64: [Select]

On Error GoTo errhandler
 
Locate -1, -1
Print "This routine is buggy!"
 
End
 
errhandler:
Print Err
Return
 

and we get an error only on fly
[ You are not allowed to view this attachment ]
the same we get if we type before RETURN and after RESUME NEXT.
Yes the error on fly doesn't happens in the first code because the statement RETURN will never be executed.

Welcome discussion and opinions.
Happy coding in QB64

FellippeHeitor · « **Reply #1 on:** September 12, 2021, 02:35:44 pm »

That's not a bug in QB64. That's just bad code.

RhoSigma · « **Reply #2 on:** September 12, 2021, 02:42:49 pm »

Why? - Because you are on the wrong side thinking on the error handler as a GOSUB like subroutine, it simply isn't.

Do you GOSUB to it? - No, its ON ERROR GOTO, not GOSUB.

It's nothing more than a simple jump to another place in your main program, and you either jump back to the same faulty line with RESUME (so to say a retry loop), to the line following the faulty line with RESUME NEXT or to a complete different place in your main program with RESUME Label.

However, in all cases the error handling is done with the RESUME statement, no need for a RETURN at all, cause its not a GOSUB called routine.

If you place a RETURN nevertheless, and the program runs over the error handler by accident, then the RESUME will do nothing, as it internally know there was no error, so I don't need to RESUME somewere. Then the next line reached in the program flow is RETURN, which of course does panic, as there was no GOSUB call in the first place.

Hence as Fellippe already stated, it's just bad code....

TempodiBasic · « **Reply #3 on:** September 12, 2021, 06:31:47 pm »

Thanks for feedbacks
Yeah it is an event trap and not an ERROR SUB.
It is another thing that uses a GOTO to jump in every place there is a label or a number of line!
I got it!
Never possible to control free jumping of GOTO!
PS Is it possible that shushi restaurant has so lowered my attention... I wrote in code GOTO and I strongly thought GOSUB!
Thanks for waking up me from that trip!

Dimster · « **Reply #4 on:** September 13, 2021, 09:47:27 am »

I learnt something too. We should coin a new phrase from "To err is human and forgive divine" to "To error is divine on QB64 forum"

Pete · « **Reply #5 on:** September 13, 2021, 11:11:16 am »

Well, the code I posted in Steve's ON ERROR THEN thread was as follows...

Code: QB64: [Select]

    ON ERROR GOTO errhandler
     
     LOCATE -1, -1
    PRINT "This routine is buggy!"
     
    END
     
    errhandler:
    PRINT ERR
    RESUME NEXT
     

So I think what may have confused my Italian compadre is the similarity to a GOSUB statement, ON ERROR error handlers must be set outside the code making up the main part of the routine or sub, unless you intend to use GOTO or conditional flagged statements to navigate around them. That makes it look similar to how we write GOSUB statements.

Now for fun...

Code: QB64: [Select]

ON ERROR GOTO Pete
 
SCREEN 90
 
Pete:
PRINT "Always program in SCREEN 0!"
ON ERROR GOTO 0
RESUME 0 ' This causes the program to redo the line that where the error was encountered.
 

Sure, it still errors. Hey, beats an infinite loop if that ON ERROR GOTO 0 wasn't included, but seriously, using RESUME 0, instead of RESUME NEXT, usually needs a condition changed in the error handler. So when the same error producing statement is repeated, the conditional change avoids the error occurring again. As an alternative to using RESUME 0 you can just use RESUME NEXT with an error flag going back into a loop.

Pete

RhoSigma · « **Reply #6 on:** September 13, 2021, 01:22:00 pm »

Well, the only real problem I'm aware of in the entire error handling logic, is a stack overflow crash, if 'RESUME label' is used extensively. I.e. if used several 1000s of times.

Just try the examples, both will generally do the same thing, running in an infinite error/retry loop. While the 1st example will happily run all into eternity (use the X button to quit), the 2nd one will crash very soon after less than 20000 loops (in the 32bit version, maybe more under 64bit).

The cause of it is the implementation of the error handling, which will simply call another instance of the QBMAIN() function. That's the function which contains your code and hence is already running. I.e. an error does cause a recursion of this function. Well, no problem if only RESUME or RESUME NEXT is used to exit from the error handler, as these are implemented as 'return' on the C++ level and hence will cleanly leave the new QBMAIN() instance, returning to the original instance (your running program). The 'RESUME label' otherwise, is implemented as 'goto label' on the C++ level, hence it just jumps to the desired label within the 2nd instance of QBMAIN(), but does not leave it. I.e. from now on the 2nd instance, which was originally initiated by the error handler call, becomes your regular running program until the next error happens and the error handler calls the next (3rd) instance of QBMAIN()..........

Code: QB64: [Select]

ON ERROR GOTO errHandler
 
LOCATE -1, -1
END
 
errHandler:
n&& = n&& + 1
PRINT LTRIM$(STR$(n&&)); ".Error"
RESUME
 

Code: QB64: [Select]

ON ERROR GOTO errHandler
 
tryAgain:
LOCATE -1, -1
END
 
errHandler:
n&& = n&& + 1
PRINT LTRIM$(STR$(n&&)); ".Error"
RESUME tryAgain
 

Pete · « **Reply #7 on:** September 13, 2021, 01:49:24 pm »

That's an interesting investigation. How about with RESUME NEXT, instead f a line number?

I usually do something using RESUME NEXT like this...

Code: QB64: [Select]

row = -1
ON ERROR GOTO er1
DO
    LOCATE , row
    IF flag THEN PRINT "A LOCATE error was made.": flag = 0 ELSE EXIT DO
LOOP
ON ERROR GOTO 0
PRINT: PRINT "Finished!"
END
 
er1:
flag = -1
INPUT "Row = "; row
RESUME NEXT

Pete

RhoSigma · « **Reply #8 on:** September 13, 2021, 02:37:44 pm »

Pete, your code is fine, RESUME NEXT doesn't have that issue.

It's just a problem, if someone does RESUME to a label/linenumber, but even then it's working for several 1000s of times, so it will probably only be an issue for programs running for long time period and getting lots of errors during runtime.

So I wouldn't be concerned too much about this recursion glitch, it won't probably hurt anybody, except in accidential cases, as it happens to me when I first got aware of it.

Pete · « **Reply #9 on:** September 13, 2021, 02:53:11 pm »

Definitely a find that deserves a place in the WIKI. I never knew about it. In ages past, on rare occasions in very large multi-modular QB45 programs, I'd get an out-of-stack-space error. I think it was almost always do to some GOSUB routine that got rerouted prior to completion. Large programs back then ate up a lot of the stack, so it didn't take much to push it over the edge.

Again, nice find, and thanks for the reply about RESUME NEXT.

Pete

News: