Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
better error trapping?
#11
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
Reply
#12
Quote:main thing ..how i see things in qb64 is checking:OFF directive
this thing is speed killer


What?
b = b + ...
Reply
#13
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 ?
Reply
#14
Yes, heading North.
b = b + ...
Reply
#15
(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
Reply
#16
(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.
Before to send the arrow of truth, dip the head in a honey pot (Cheyenne saying).
Don't tell my Mom I'm on iMac with macOS, she thinks I work on PC with Windows. Tongue
Reply




Users browsing this thread: 4 Guest(s)