06-14-2022, 04:46 AM
> What is AndAlso supposed to do anyway, that can't be done with normal if then else elseif ?
It's a short-circuiting operator, so it's the same as a regular
> Is it something like "finally" in a try catch block?
Well we're kinda mixing a lot of different things here
try-catch-finally involve exceptions, which end up jumping over whole blocks of code. Personally I don't really like exceptions, but it is what it is. 'finally' blocks can be useful for ensuring that resources get cleaned up even when an exception is thrown. Say you need to close a file with
> But speaking of try/catch and if we're talking making improvements, how about adding improved error handling? As is, QB64's ON ERROR GOTO is awfully limited - you can't even GOTO a line inside a function, it has to be a label defined somewhere in the main code. What we need is ON ERROR RESUME NEXT that works like it does in VBA, or a simple TRY/CATCH. I've been living without it for the 2+ years since I've dove into QB64, but improving the scope of error handling would be a nice upgrade!
I've been thinking about this a bit as well, but I don't have anything concrete. I agree the current situation stinks, I think in general it would be nice if we had something like
That said I haven't really fleshed anything out yet (and it's not really on my todo list, it's just an annoyance whenever I program in QB64), perhaps it would be better to revamp the whole thing entirely. Also, there's also the messy detail that the error handling we have is not really consistent, new functions like
It's a short-circuiting operator, so it's the same as a regular
ANDbut the argument on the left is evaluated first, and if the result is false then the right side is never evaluated at all. It can have some benefits because the left side might be checking that the right side can be evaluated at all (without producing an error). I'm not sure I'd say it's really necessary, but either way the short circuiting nature of it means it can't be implemented as a regular function, as all function arguments are evaluated before calling the function.
> Is it something like "finally" in a try catch block?
Well we're kinda mixing a lot of different things here
try-catch-finally involve exceptions, which end up jumping over whole blocks of code. Personally I don't really like exceptions, but it is what it is. 'finally' blocks can be useful for ensuring that resources get cleaned up even when an exception is thrown. Say you need to close a file with CLOSE, but an exception is thrown while you have the file open, so your
CLOSEgets skipped. If you put it in a
finallyblock it's guaranteed to run even if an exception gets thrown at some point. Of course there are better patterns than this, but it is an option.
> But speaking of try/catch and if we're talking making improvements, how about adding improved error handling? As is, QB64's ON ERROR GOTO is awfully limited - you can't even GOTO a line inside a function, it has to be a label defined somewhere in the main code. What we need is ON ERROR RESUME NEXT that works like it does in VBA, or a simple TRY/CATCH. I've been living without it for the 2+ years since I've dove into QB64, but improving the scope of error handling would be a nice upgrade!
I've been thinking about this a bit as well, but I don't have anything concrete. I agree the current situation stinks, I think in general it would be nice if we had something like
ON ERROR RESUME NEXTand then could just check if
ERR <> 0to determine if an error occurred on the last statement. Still not amazing, but much more flexible and probably wouldn't require huge changes to the language to support it.
That said I haven't really fleshed anything out yet (and it's not really on my todo list, it's just an annoyance whenever I program in QB64
), perhaps it would be better to revamp the whole thing entirely. Also, there's also the messy detail that the error handling we have is not really consistent, new functions like _LOADIMAGE()do indicate if the file can't be opened without an ON ERROR happening. And then there's that sticky "backwards compatibility" issue ;D ...