better error trapping?

[madscijr]

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?

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.

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.