Posts: 205
Threads: 13
Joined: Apr 2022
Reputation:
50
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.
Posts: 2,128
Threads: 218
Joined: Apr 2022
Reputation:
100
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
Fake News + Phony Politicians = Real Problems
Posts: 1,277
Threads: 120
Joined: Apr 2022
Reputation:
100
(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.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 2,128
Threads: 218
Joined: Apr 2022
Reputation:
100
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
Fake News + Phony Politicians = Real Problems
Posts: 35
Threads: 4
Joined: Apr 2022
Reputation:
14
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.
Posts: 205
Threads: 13
Joined: Apr 2022
Reputation:
50
08-17-2024, 02:10 PM
(This post was last modified: 08-17-2024, 04:08 PM by RhoSigma.)
(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.
Posts: 1,277
Threads: 120
Joined: Apr 2022
Reputation:
100
(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.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 2,128
Threads: 218
Joined: Apr 2022
Reputation:
100
Agreed!
Pete
Fake News + Phony Politicians = Real Problems
Posts: 369
Threads: 71
Joined: Jul 2022
Reputation:
14
(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.
|