Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ON ERROR question
#11
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.
Reply
#12
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

Reply
#13
(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
Reply
#14
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

Reply
#15
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.
Reply
#16
(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.
Reply
#17
(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
Reply
#18
Agreed! Cool 

Pete
Fake News + Phony Politicians = Real Problems

Reply
#19
(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.
Reply




Users browsing this thread: 1 Guest(s)