ON ERROR THEN

[SMcNeill]

Jaze posted a cryptogram program earlier which the code led me to thinking: Why isn’t there an ON ERROR THEN syntax?

We have both version for IF:

IF X THEN…

IF X GOTO…

Why do we have to have:

ON ERROR GOTO crap
GOTO beginning
crap:
PRINT "Error, Line number"
PRINT ERR, _ERRORLINE
END
beginning:


Why isn’t there a simple:

ON ERROR THEN
    PRINT "Error, Line number"
    PRINT ERR, _ERRORLINE
END ON ERROR

[Pete]

I saw that post, too. My take is this. ON ERROR is best used as...

Code: QB64: [Select]

1. ON ERROR GOTO errhandler
2.  
3.  LOCATE -1, -1
4. PRINT "This routine is buggy!"
5.  
6. END
7.  
8. errhandler:
9. PRINT err
10. RESUME NEXT
11.  

No need to shunt around an error handler with something like "GOTO beginning" when it is used in this fashion. Also, it is an exception of GOTO where the developers made it possible to place the error handler in the main, while allowing ON ERROR GOTO to be placed in subs. The only complaint I had (back in the day) was in multi-modular programming, one had to make an error handler for each module. There was no way to make a universal error handler back then. Nowadays, multi-modular programming is completely unnecessary.

Pete

 

[Jaze]

Looking at what was said about me going around the error portion with "GOTO beginning". If I took out the label and the GOTO would the ide simply pass the ERROR label? How exactly should that work?  Btw, didn't know ON ERROR could be used in a SUB, so thanks for that.

[Qwerkey]

I agree with Steve.  I hate using ON ERROR GOTO which requires the two labels and code stepping over each other.  A hand-me-down from QB2 (or the original BASIC?).

When the team have come up with the new ON ERROR THEN, could we have it with an ELSE as well:

ON ERROR THEN

    PRINT "Point out to that idiot Qwerkey that he has made yet another stupid error in his code."
    PRINT "Why did we ever let this fool anywhere near QB64?"
    PRINT ERR, _ERRORLINE

    ELSE
   
    ' Carry on with the rest of Qwerkey's amazing Masterwork of efficiently written QB64 code.

END ON ERROR

[bplus]

Code: QB64: [Select]

1. Why do we have to have:
2.  
3. ON ERROR GOTO crap

Dollars to donuts it's for compatibility with old code.

Plus, what a mess it would make of using a THEN for an IF block.

[TempodiBasic]

Hi brothers and sisters
just some philosophical thoughts about
ON ERROR GOTO  &&  ON ERROR THEN  && ON ERROR THEN......END ON ERROR


1. goal of ON ERROR GOTO is clearly managing the exception to the normal (planned) flow of program so the ELSE is still managed by code 

Code: QB64: [Select]

1. On Error GoTo NextVideoMode
2. A = 0
3. While A < 14
4.     Screen A
5.     Line (10, 10)-(100, 100), 14
6.     Print " Press a key to continue"
7.     Sleep
8.     A = A + 1
9. Wend
10.  
11. End
12.  
13. NextVideoMode:
14. A = A + 1
15. Print " Error: Screen mode = "; A - 1
16. Sleep 2
17. If A = 14 Then On Error GoTo 0 Else Screen A
18. Resume

2. I have seen code with ON ERROR GOTO to manage issues like File not found, VideoMode not avaiable indeed illegal funtion call for a graphic statement , out of DATA, Subscritpt Out of Range. For many of these we have specific _QB64 _Keywords to verify to avoid the error on fly.

3. the GOTO /RESUME / RESUME NEXT(Yeah only QB PDS) is an haitful old fashioned structure. But it works!
Yes I would prefer ON ERROR THEN (one line statement without ELSE or END ON ERROR but just the first primitive IF...THEN) to call directly the sub managing the error, so the code to manage can be used also in a recursive way but to get this I must only put the name of SUB just between ErrorLabel:  and  RESUME

Code: QB64: [Select]

1. ON ERROR GOTO ThisIsAnError
2.  
3. 'program instructions...
4.  
5. ON ERROR GOTO 0
6. END
7.  
8. SUB SolveError
9. ' it makes the right changements
10. END SUB
11.  
12. ThisIsAnError:
13.  SolveError
14. RESUME
15.  

Why don't like multiple lines ON ERROR THEN?
Because in a sub you can put as many as statements and controls you want to have.
So we can do that without developing more keywords.

PS just some mine thoughts. Don't mind