|
Post by meerkat on Aug 27, 2020 14:03:38 GMT -5
Would it be possible to report SQL errors and let the program continue. Currently if you get a SQL error everything is locked. Far as I know, you cannot set the 'on error' to null. To get around this, I create a FUNCTION sqlTest$(sql$) to test the SQL. The function sets the sql LIMIT to 1 and uses a 'on error' to localize the error within the FUNCTION and return the error.
|
|
|
Post by Brandon Parker on Aug 28, 2020 14:29:43 GMT -5
In my opinion, localizing "On Error" traps is the safest way to go about things where errors outside of the programmer's control might occur. This ensures that you can recover from the error in most cases with little to no chance of blowing up the stack or something. This is just my opinion though ... {:0) Brandon Parker
|
|
|
Post by meerkat on Aug 29, 2020 4:30:38 GMT -5
I guess you and I have different opinions. If it were possible to turn off the on error. You could localize errors by using on error goto [sqlErr] right before the sql statement. After the sql, turn it off with something like on error goto NULL or goto 0
If someone can show me how to turn off on error, this request is mute.
Thanks for the help.
|
|
|
Post by Brandon Parker on Aug 29, 2020 15:25:03 GMT -5
We can definitely have differing opinions but in Computer Science it is mostly recommended to handle errors at the stack level where the error occurs since going back to the root of the stack will destroy any locally scoped things that were going on in the intermediary levels.
The root error handler (i.e. the one completely outside of any Subroutine/Function should be the Error Handler of last resort in the case that the program has done everything in its power to correct issues, but it cannot continue.
What you want to do is very simple in Liberty BASIC. All you have to do is simply declare a different Error Handler prior to executing whatever code requires that Error Handler, and then redeclare the original one after the other code has completed. This gets very cumbersome though and results in "Spaghetti Code" in my opinion.
Here is an example of what I think you want to do. Works in LB 4.5.1 ...
'Declare our initial Error Handler On Error GoTo [Error] a = 0 Print 1/a Print
'Declare a temporary Error Handler On Error GoTo [TemporaryError] a = 0 Print 1/a Print
'Redeclare our initial Error Handler On Error GoTo [Error] a = 0 Print 1/a
End
[Error] Print "Initial Error Handler: Division by Zero!" a = 1 Resume
[TemporaryError] Print "Temporary Error Handler: Division by Zero Again!" a = 2 Resume
{:0)
Brandon Parker
|
|
|
Post by metro on Aug 29, 2020 18:47:15 GMT -5
We can definitely have differing opinions but in Computer Science it is mostly recommended to handle errors at the stack level where the error occurs since going back to the root of the stack will destroy any locally scoped things that were going on in the intermediary levels. The root error handler (i.e. the one completely outside of any Subroutine/Function should be the Error Handler of last resort in the case that the program has done everything in its power to correct issues, but it cannot continue. What you want to do is very simple in Liberty BASIC. All you have to do is simply declare a different Error Handler prior to executing whatever code requires that Error Handler, and then redeclare the original one after the other code has completed. This gets very cumbersome though and results in "Spaghetti Code" in my opinion. Resume {:0) Brandon Parker I maybe wrong here , but like RunBasic "resume" is not implemented in lb5 and maybe wrong again I think that is what Dan is eluding to, you can't recover from the error or at least it's not obvious how to recover.
|
|
|
Post by Brandon Parker on Aug 29, 2020 19:54:30 GMT -5
See the quote below from my post above... Here is an example of what I think you want to do. Works in LB 4.5.1 ... Indeed "Resume" is not implemented in LB5 yet, but LB5 is still in Alpha release. The Wishlist is just general wishes for things in LB. No mention of version was specified by Dan, but I most certainly specified that what I posted works in LB 4.5.1, as shown above, for the specific reason that "Resume" is not implemented in the current LB5 Alpha release. Furthermore, and in my opinion, one should not be using LB5 to build out a program in its current state unless it is just for testing because things can & will change over time as LB5 is developed by Carl. We are all cheering for you Carl!!!! Should anyone REALLY want to handle errors in a reliable manner I would HIGHLY suggest that person consider trapping errors within Subroutines/Functions that way errors can be handled in the stack level where the error occurs and to reduce "Spaghetti Code Syndrome" in programs. This is the whole reason WHY error handling (exception handling in other languages) is allowed in Subroutines/Functions. I embraced this a long time ago when I first start writing my Dynamic Array library for Liberty BASIC; actually, it is the ONLY reason the library can do what it does. {:0) Brandon Parker
|
|
|
Post by meerkat on Aug 30, 2020 6:34:27 GMT -5
Ya! Laurie. In LB5 if you get a error, your program quits working. Currently I'm testing errors in FUNCTIONS. But they are specific like testing SQL commands. However you can get unexpected errors, and your program quits. Would be great if you could do a generic 'on error' , print the error code and message then resume:
something like:
' -- generic on error on error goto [error] . . ' assuming err would be the error code and err$ is the error message [error] ' will test err to determine what should happen notice "** Error code:":err;" Message:";err$;chr$(13);"** Notify systems" on error goto [error] 'reset the generic error resume
Thanks for the help. Dan
|
|
|
Post by Brandon Parker on Aug 30, 2020 20:55:41 GMT -5
LB5 still seems to have issues while attempting to exiting Subroutines/Functions which is how you would normally exit prior to invoking the error label below the normal code (as long as you format it that way). Exiting a Function causes an LB fatal error, and attempting to exit a Subroutine just does nothing at all. This is why I would stick with LB4.5.1 for full-fledged programs and only use LB5 Alpha for testing purposes.
Here is some code that shows the issues. The error trapping works perfectly fine, but the issues arise when the error trapping is not required.
Call testSubroutine 0 Call testSubroutine 2
Print testFunction(0) Print testFunction(2)
Function testFunction(x) On Error GoTo [Error] testFunction = (1/ x) Exit Function [Error] Print err;" : ";err$ End Function
Sub testSubroutine x On Error GoTo [Error] Print (1/ x) Exit Sub [Error] Print err;" : ";err$ End Sub
{:0)
Brandon Parker
|
|