(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
