better error trapping? - Printable Version

better error trapping? - Printable Version

+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: better error trapping? (/showthread.php?tid=1372)

Pages: 1 2

RE: better error trapping? - aurel - 01-08-2023

My point is that BASIC should not care about "exception handling" is possible..? of course
and because FB tendencies to force OOP and other craps into BASIC i never liked it very much.

BUT FB is very powerful ..just to be clear

main thing ..how i see things in qb64 is checking:OFF directive
this thing is speed killer

RE: better error trapping? - bplus - 01-08-2023

Quote:main thing ..how i see things in qb64 is checking:OFF directive
this thing is speed killer

What?

RE: better error trapping? - aurel - 01-08-2023

I mean checking ON
there is no need for error checking at runtime
so every program at final stage should include cheking:OFF

is that OK ?

RE: better error trapping? - bplus - 01-08-2023

Yes, heading North.

RE: better error trapping? - DSMan195276 - 01-08-2023

(01-08-2023, 05:18 PM)aurel Wrote: I mean checking ON
there is no need for error checking at runtime
so every program at final stage should include cheking:OFF

is that OK ?

$Checking:Off

changes the behavior of your program, for example timers will not fire in

$Checking:Off

regions. Generally speaking you shouldn't use it for your whole program unless you're confident you don't need any of the things it prevents from happening. IMO it's mostly just a hack, not something you want to be using often.

Additionally some errors are unavoidable and ok, for example

OPEN

will error if the file cannot be accessed, and if you allow the user to provide the file location then you cannot control what will happen. There are some sanity checks you can do (Ex.

_FILEEXISTS

) but there's no way to be sure it won't error without just trying to open it and handling the error if it comes up.

Beyond that, my opinion somewhat the same as @madscijr and @Spriggsy, which is that the error handling that already exists is not terrible but the need to use a GOTO that is placed in the main section of code is unacceptable. I personally don't think

_TRY/_CATCH

would be all that bad, it would really just be a way of defining a local GOTO section for errors (and

_CATCH

would give you the error code), but there might be a nicer way to do it.

Regardless of how it works I think the main goal would be the ability to handle errors from directly inside a Function/Sub without needing to rely on any code in the main section. Additionally you shouldn't have to change the global error handling setting or otherwise should be able to save and restore it, so that you can handle errors and then leave things the same as they were when your Function/Sub was called.

Edit: A further note on

$Checking:Off

, it does _not_ prevent errors from happening, it just prevents them from being handled. Many commands do not do anything if an error is pending, so if an error happens your program will not trigger an error handler but also will no longer work correctly. Some commands (mostly commands that sleep) also directly trigger the error handling, so even a

$Checking:Off

program has the potential to still have an error get triggered and either call an error handler or pop-up the dialog.

This example I made that triggers an error even though

$Checking:Off

is applied to the whole program, demonstrating what I'm talking about:

Code: (Select All)
$Checking:Off

On Timer(1) GoSub timerhand

On Error GoTo errorhand

Timer On

Print "Does it trigger an error?"

_Delay 5

End

timerhand:

Error 64

Return

errorhand:

Print "Yes!"

Resume

RE: better error trapping? - Fifi - 01-09-2023

(01-08-2023, 09:50 AM)mnrvovrfc Wrote: And so we would never hear the end of it after either QB64 or Freebasic obtains OOP features. In the very least the ability to overload a subprogram or function. It's their reaction to, "It's too slow", they would answer, "Yes but it's industry standard." No it's not. Maybe it was and I'm one of the many that don't care if it was.

The thing is that exception handling is possible without OOP but it would look strange to somebody accustomed to Java, let's say. Some people want it for BASIC away from payware but it would complicate things. The programmer that really wants it could certainly kiss goodbye the "small" code that must run on 16-bit as well as 64-bit. IINM QB64PE employs a few things that do not work on operating systems earlier than Windows Vista because it has to involve at least one case where it's possible to throw an error. Might do it on purpose only to test, or to obtain a side-effect.

I know less about that than eg. Spriggsy who seems to be very good at Powershell.

Hello mnrvovrfc,
It's not possible to send you a private message.
This is in order to respond to your tag.
TIA to unlock the private message option in your profile.