QB64 Phoenix Edition
ON ERROR question - Printable Version

+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: ON ERROR question (/showthread.php?tid=2956)

Pages: 1 2

RE: ON ERROR question - RhoSigma - 08-16-2024

I see one big problem here, let's say I use your colordepth library, so you set the handler to label COLORDEPTH_BIFILE and in the end you simply reset the handler (ON ERROR GOTO 0). But what is when I had a handler label "MyDumbErrHandler" active before calling the Colordepth function, and my following code assumes it points still to that handler?

Currently there's no way in the language to figure out where's the current error handler is pointing to, so I'd strongly suggest not to change it in external library code, as you can't correctly restore it to the original state.

RE: ON ERROR question - Pete - 08-16-2024

Gotcha...

So I thought I'd throw a skeleton together for myself, in case I ever want to take advantage of INCLUDE files.

Main:
Code: (Select All)
Dim Shared erh As Integer

Do

    Cls

    Input "Value for i:"; i

    pete1

    pete2 (i)

    Sleep 5

    If InKey$ = Chr$(27) Then Exit Do

Loop

End



handler:

erh = Err

Resume Next



'$Include: 'Pete1.bm'

'$Include: 'Pete2.bm'

Pete1 library:
Code: (Select All)
Sub pete1

    Print "Pete 1"

End Sub

Pete2 library:
Code: (Select All)
Sub pete2 (i)

    On Error GoTo handler

    Locate i, 20

    If erh Then Beep: Erh = 0: Exit Sub

    Print "Pete 2"

End Sub

Pete

RE: ON ERROR question - TerryRitchie - 08-17-2024

(08-16-2024, 10:58 PM)RhoSigma Wrote: I see one big problem here, let's say I use your colordepth library, so you set the handler to label COLORDEPTH_BIFILE and in the end you simply reset the handler (ON ERROR GOTO 0). But what is when I had a handler label "MyDumbErrHandler" active before calling the Colordepth function, and my following code assumes it points still to that handler?

Currently there's no way in the language to figure out where's the current error handler is pointing to, so I'd strongly suggest not to change it in external library code, as you can't correctly restore it to the original state.
Well poo, I was thinking about that too. What's needed is a way to test if image handles are valid.

RE: ON ERROR question - Pete - 08-17-2024

Yeah poo^2

This reminds me of why I punted on libraries years ago. Way too difficult to get a universal application.

Rho is spot on with no way around it. 

For my apps, I always made a master error handling routine. Now for QuickBASIC, if you did multi-modular programming, you had to duplicate your error handler in each module!

It would be a neat feature if there was a developed method to return control back to a previously called error handler, instead of "0" which just removes all error handling.

Well it's like my grandma always told me, my little Rosanne Rosannadanna, it's always something!

Pete

RE: ON ERROR question - luke - 08-17-2024

QB 7.1 has an ON LOCAL ERROR command which deals with this, you use it in a SUB/FUNCTION and it jumps to a label in that subprocedure. When you exit the subprocedure, the local error handler is removed and the previous error handler (the global ON ERROR or another ON LOCAL ERROR in the caller) comes back into effect.

Possibly something to adapt into QB64 at some point.

RE: ON ERROR question - RhoSigma - 08-17-2024

(08-17-2024, 02:53 AM)TerryRitchie Wrote:
(08-16-2024, 10:58 PM)RhoSigma Wrote: I see one big problem here, let's say I use your colordepth library, so you set the handler to label COLORDEPTH_BIFILE and in the end you simply reset the handler (ON ERROR GOTO 0). But what is when I had a handler label "MyDumbErrHandler" active before calling the Colordepth function, and my following code assumes it points still to that handler?

Currently there's no way in the language to figure out where's the current error handler is pointing to, so I'd strongly suggest not to change it in external library code, as you can't correctly restore it to the original state.
Well poo, I was thinking about that too. What's needed is a way to test if image handles are valid.

So as it appears to me a method to restore to a previous error handler can be done pretty simple.

ON ERROR GOTO handler 'regularly set a handler
ON ERROR GOTO 0 'regularly disable programmatically error handling

ON ERROR GOTO _LASTHANDLER 'restore to the previous handler

However, if _LASTHANDLER is used without a hander set previously, then we could throw an runtime error or simply restore it to ON ERROR GOTO 0 silently. The latter is better I guess.

RE: ON ERROR question - TerryRitchie - 08-17-2024

(08-17-2024, 02:10 PM)RhoSigma Wrote:
(08-17-2024, 02:53 AM)TerryRitchie Wrote:
(08-16-2024, 10:58 PM)RhoSigma Wrote: I see one big problem here, let's say I use your colordepth library, so you set the handler to label COLORDEPTH_BIFILE and in the end you simply reset the handler (ON ERROR GOTO 0). But what is when I had a handler label "MyDumbErrHandler" active before calling the Colordepth function, and my following code assumes it points still to that handler?

Currently there's no way in the language to figure out where's the current error handler is pointing to, so I'd strongly suggest not to change it in external library code, as you can't correctly restore it to the original state.
Well poo, I was thinking about that too. What's needed is a way to test if image handles are valid.

So as it appears to me a method to restore to a previous error handler can be done pretty simple.

ON ERROR GOTO handler 'regularly set a handler
ON ERROR GOTO 0 'regularly disable programmatically error handling

ON ERROR GOTO _LASTHANDLER 'restore to the previous handler

However, if _LASTHANDLER is used without a hander set previously, then we could throw an runtime error or simply restore it to ON ERROR GOTO 0 silently. The latter is better I guess.
That would be a very welcome addition.

RE: ON ERROR question - Pete - 08-19-2024

Agreed! Cool 

Pete

RE: ON ERROR question - eoredson - 09-02-2024

(08-17-2024, 11:58 AM)luke Wrote: QB 7.1 has an ON LOCAL ERROR command which deals with this, you use it in a SUB/FUNCTION and it jumps to a label in that subprocedure. When you exit the subprocedure, the local error handler is removed and the previous error handler (the global ON ERROR or another ON LOCAL ERROR in the caller) comes back into effect.

Possibly something to adapt into QB64 at some point.
I have used On Local Error extensively in QB 7.1 projects and works well.

Yes, it should be added to QB64..

Erik.