Posts: 218
Threads: 11
Joined: Apr 2022
Reputation:
49
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,130
Threads: 212
Joined: Apr 2022
Reputation:
97
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,221
Threads: 114
Joined: Apr 2022
Reputation:
97
(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.
There are two ways to write error-free programs; only the third one works.
QB64 Tutorial
Posts: 2,130
Threads: 212
Joined: Apr 2022
Reputation:
97
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: 32
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: 218
Threads: 11
Joined: Apr 2022
Reputation:
49
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,221
Threads: 114
Joined: Apr 2022
Reputation:
97
(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.
There are two ways to write error-free programs; only the third one works.
QB64 Tutorial
Posts: 2,130
Threads: 212
Joined: Apr 2022
Reputation:
97
Agreed!
Pete
Fake News + Phony Politicians = Real Problems
Posts: 352
Threads: 69
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.
|