+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: better error trapping? (/showthread.php?tid=1372)
Pages:
1
2
better error trapping? - madscijr - 01-06-2023
With http/s capability coming, QB64PE is getting a major feature set.
With that out of the way, I was thinking that another big feature for an upcoming release would be try/catch functionality. Even basic "on error resume next", like in classic VB/VBA, would be an improvement, or full try/catch like every other modern language.
Thoughts?
RE: better error trapping? - SpriggsySpriggs - 01-06-2023
You can emulate the try/catch by setting up a block with an "on error goto". A try catch would be quite nice, though. Even if it means it will be _TRY _CATCH..... blegh.... Thank God for $NOPREFIX.
Something I just thought about, though, would be that you'd only be catching exceptions that QB64 runtime throws. It wouldn't be useful for someone like me, who uses external libraries and wouldn't have the ability to catch exceptions from the libraries in this way. I'd have to stick to if statements and GetLastError instead.
RE: better error trapping? - madscijr - 01-06-2023
(01-06-2023, 08:07 PM)Spriggsy Wrote: You can emulate the try/catch by setting up a block with an "on error goto". A try catch would be quite nice, though. Even if it means it will be _TRY _CATCH..... blegh.... Thank God for $NOPREFIX.
Something I just thought about, though, would be that you'd only be catching exceptions that QB64 runtime throws. It wouldn't be useful for someone like me, who uses external libraries and wouldn't have the ability to catch exceptions from the libraries in this way. I'd have to stick to if statements and GetLastError instead.
The big problem with "on error goto" is, well, firstly, it uses GOTO! And even worse is that in QB64/PE, the compiler won't let the target of the GOTO be inside of a function or sub, or inbetween routines, it has to appear before any functions/subs. So now we're jumping somewhere outside the function - convoluted. In VB6/VBA (but not VBSCRIPT!) the error handling code can at least be put inside the routine itself.
I prefer ON ERROR RESUME NEXT, and then testing if err.number <> 0 then [handle error and err.clear].
But an inline try/catch is just cleaner. I don't know about error handling for external APIs, how do .NET, Java, JavaScript, or Python implement it? It's been a loooong time since I did .NET, but I do remember the error object was pretty rich, it even had stack trace! I don't recall anything about what details bubbled up from an exception originating from an external dependency, but I would think if the QB64PE runtime calls an external library, it's up to the library to catch exceptions and to send back some kind of meaningful error code or message? Because otherwise wouldn't it just freeze up and time out?
RE: better error trapping? - SpriggsySpriggs - 01-06-2023
(01-06-2023, 09:29 PM)madscijr Wrote:The external libraries that I've seen don't send back an exception (I think this is just due to how things are handled with C/C++ vs C#). Error codes, sure. But you have to handle that yourself and there is no cookie cutter way of doing it since they all handle error codes differently. And, most of the time, they just freeze up and/or crash if you've really screwed up. There really is no good way to catch "exceptions" in these external libraries.(01-06-2023, 08:07 PM)Spriggsy Wrote: You can emulate the try/catch by setting up a block with an "on error goto". A try catch would be quite nice, though. Even if it means it will be _TRY _CATCH..... blegh.... Thank God for $NOPREFIX.
Something I just thought about, though, would be that you'd only be catching exceptions that QB64 runtime throws. It wouldn't be useful for someone like me, who uses external libraries and wouldn't have the ability to catch exceptions from the libraries in this way. I'd have to stick to if statements and GetLastError instead.
The big problem with "on error goto" is, well, firstly, it uses GOTO! And even worse is that in QB64/PE, the compiler won't let the target of the GOTO be inside of a function or sub, or inbetween routines, it has to appear before any functions/subs. So now we're jumping somewhere outside the function - convoluted. In VB6/VBA (but not VBSCRIPT!) the error handling code can at least be put inside the routine itself.
I prefer ON ERROR RESUME NEXT, and then testing if err.number <> 0 then [handle error and err.clear].
But an inline try/catch is just cleaner. I don't know about error handling for external APIs, how do .NET, Java, JavaScript, or Python implement it? It's been a loooong time since I did .NET, but I do remember the error object was pretty rich, it even had stack trace! I don't recall anything about what details bubbled up from an exception originating from an external dependency, but I would think if the QB64PE runtime calls an external library, it's up to the library to catch exceptions and to send back some kind of meaningful error code or message? Because otherwise wouldn't it just freeze up and time out?
RE: better error trapping? - mnrvovrfc - 01-06-2023
(01-06-2023, 08:07 PM)Spriggsy Wrote: You can emulate the try/catch by setting up a block with an "on error goto". A try catch would be quite nice, though. Even if it means it will be _TRY _CATCH..... blegh.... Thank God for $NOPREFIX.
C++ exception handling was one of the worst things to add to that language. Thank God for no "_TRY", "_CATCH", "_EXCEPT", "_FINALLY" or "_WHATEVER". And I prefer the underscores and dislike "$NOPREFIX", thank you.
Oh well, if QB64PE obtains object-oriented programming features then exception handling is inevitable. People are going to heavily expect both, not one or the other. Freebasic doesn't have exception handling yet but I'll bet some programmers are begging for it to make it like C++ as much as possible.
From:
https://www.freebasic.net/wiki/ProPgErrorHandling
Quote:Future OOP versions of FreeBASIC may have a java-like TRY..CATCH...FINALLY exception handler implemented.
LOL Java-like?
(01-06-2023, 09:42 PM)Spriggsy Wrote: There really is no good way to catch "exceptions" in these external libraries.
This is even more true with Linux with the bunch of desktop environments and window managers. GNOME and KDE each one are complex beasts. The Flatpaks seems to rely heavily on GNOME stuff but it doesn't mean it's fairly easy to catch errors. The KDE folks are still having trouble getting even simple screen drawing done correctly and reliably, which is another thing. XFCE is not as popular with people coming over from MacOS and Windows and therefore less programmers would know about exception handling through GUI with that D.E.
RE: better error trapping? - madscijr - 01-07-2023
(01-06-2023, 09:42 PM)Spriggsy Wrote:(01-06-2023, 09:29 PM)madscijr Wrote:The external libraries that I've seen don't send back an exception (I think this is just due to how things are handled with C/C++ vs C#). Error codes, sure. But you have to handle that yourself and there is no cookie cutter way of doing it since they all handle error codes differently. And, most of the time, they just freeze up and/or crash if you've really screwed up. There really is no good way to catch "exceptions" in these external libraries.(01-06-2023, 08:07 PM)Spriggsy Wrote: You can emulate the try/catch by setting up a block with an "on error goto". A try catch would be quite nice, though. Even if it means it will be _TRY _CATCH..... blegh.... Thank God for $NOPREFIX.
Something I just thought about, though, would be that you'd only be catching exceptions that QB64 runtime throws. It wouldn't be useful for someone like me, who uses external libraries and wouldn't have the ability to catch exceptions from the libraries in this way. I'd have to stick to if statements and GetLastError instead.
The big problem with "on error goto" is, well, firstly, it uses GOTO! And even worse is that in QB64/PE, the compiler won't let the target of the GOTO be inside of a function or sub, or inbetween routines, it has to appear before any functions/subs. So now we're jumping somewhere outside the function - convoluted. In VB6/VBA (but not VBSCRIPT!) the error handling code can at least be put inside the routine itself.
I prefer ON ERROR RESUME NEXT, and then testing if err.number <> 0 then [handle error and err.clear].
But an inline try/catch is just cleaner. I don't know about error handling for external APIs, how do .NET, Java, JavaScript, or Python implement it? It's been a loooong time since I did .NET, but I do remember the error object was pretty rich, it even had stack trace! I don't recall anything about what details bubbled up from an exception originating from an external dependency, but I would think if the QB64PE runtime calls an external library, it's up to the library to catch exceptions and to send back some kind of meaningful error code or message? Because otherwise wouldn't it just freeze up and time out?
Well, being able to do an on error resume next and then pick up an error code is better than on error goto and the location can't even be in the local scope.
RE: better error trapping? - mnrvovrfc - 01-07-2023
Will have to wait for the "ON ERROR RESUME NEXT" to be implemented, and the requests will have to multiply including actual source code situations. To me that seems like another lazy way to program; it's dangerous to pass along signs of danger. Something like that must be all over Audacity which prevents it from loading much more than 20 wave files and, at least at my end, I have to log out and back in to regain control of my computer. Moreover, that program has a serious problem with the menu handler.
RE: better error trapping? - madscijr - 01-08-2023
(01-07-2023, 03:38 AM)mnrvovrfc Wrote: Will have to wait for the "ON ERROR RESUME NEXT" to be implemented, and the requests will have to multiply including actual source code situations. To me that seems like another lazy way to program; it's dangerous to pass along signs of danger. Something like that must be all over Audacity which prevents it from loading much more than 20 wave files and, at least at my end, I have to log out and back in to regain control of my computer. Moreover, that program has a serious problem with the menu handler.
I guess it comes down to a difference in philosophy, but in my experience, there's nothing dangerous about being able to detect an error to take action. A try/catch beats out having no error handling and just letting your app blow up, every time. I can see no situation where you wouldn't want graceful error handling. In the very least, at least fix on error/goto, to enable it to goto a location in the same scope.
RE: better error trapping? - aurel - 01-08-2023
Quote:Freebasic doesn't have exception handling yet but I'll bet some programmers are begging for it to make it like C++ as much as possible.
There are some "experts" inside FB community which main goal was to make every FB program in a OOP way
patronizing that way is the only good way ...where is bASIC there?
also i recently get proof of OOP way of program made in FB with lot of includes
that program compile time was cca 20 seconds on my computer ..and one the end perform slow
RE: better error trapping? - mnrvovrfc - 01-08-2023
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.