It's in out of QA and into the queue of bugs to be worked on, but it has not been assigned to an engineer yet.
Jump to content
I'm looking at this issue and will report back when I have more news.
I agree that the handling of runtime errors needs to be more consistent but I'm not sure that a programming methodology that depends on suppressing them is a recipe for success. In the cited example, relying on a runtime error when getting an unexpected result from a network call is all very well but what if the bad result just causes incorrect behavior in the game and doesn't raise a runtime error? The consistency of the data needs to be checked whether or not runtime errors are generated (the good news is that TCP/IP is a reliable method of communication and, if you receive the number of bytes the servers says it sent, you can assume the data is good presuming the server is reliable).
Note that even when the unhandledError listener is working correctly, the current Lua context stops execution at the point of the error and the code in the unhandledError listener is then run and the context ends. You can't continue from a runtime error in Lua. The unhandledError listener just allows you to know when one happened (when it's working correctly).
Also, divide by zero doesn't cause a runtime error in Lua: 5 / 0 evaluates to inf
Just so I'm clear, it's only network request callbacks that have this issue, correct?
I've tested various other kinds of listeners (e.g. tap) and all stop the app's execution if they encounter a runtime error (and showRuntimeErrors is set appropriately). A fix for network listeners will be forthcoming after some more testing.
@Perry, I was doing some more research today and found another area that is affected. I use a lot of scene overlays - infact apart from my main scene every other scene is an overlay. I am still using Storyboard (but I doubt this makes any difference as this is out of scope for Storyboard code).
I use scene:overlayEnded() to process responses from my overlays. Often I will call functions from the callback to handle certain responses, update UI or change things in my game. I noticed today that one of those functions was silently failing - no runtime error and nothing in the console. Ironically it was hitting a divide by 0 and processing halted without any form of error. When I added an "if 0 don't divide" check and magically the function now completes as expected.
So functions fired from callbacks, not only network callbacks is also affected. I can't really post code as I was nested 4 functions deep.
In summary, whilst 1/0 may not raise an error per sae, id does silently break code execution in callback functions.
I can't speak to how the logic in your app handles the divide by zero in question but a divide by zero is not an error and does not affect the flow of execution (unless, obviously, said flow depends on the result of the divide which is likely or the divide would be unnecessary).
Put these lines in a listener (or anywhere else) and they will always both be executed (they are for me):
print("Dividing by zero: ", 5 / 0) print("After dividing by zero")
If you still think it's a problem, send me a minimal app that demonstrates the issue.
Can you confirm if you just want a minimal app for the divide by zero or for my original post? I thought that it was clear what the issue was and that it had been confirmed to be a problem.
I have not been mentioning divide by zero and I am worried that that has not become a distraction from what the original problem was - e.g. any call placed within a network.request listener will not generate a "true" runtime error.
BTW - in you above post you mention Print to validate that the app continues to run - the print statement outputs to the build window. If you read earlier posts the build window is where the runtime error is output. The issue is that in the App (and the Corona Simulator) no error is generated (even though an error is detailed in the build window).
The Daily Build with the fix for this issue (that runtime errors in network listeners did not display an error dialog in debug builds nor did they run an unhandledError listener if one was defined) is available: CoronaSDK 2017.3075. Note that by default non-debug builds have never displayed error dialogs for runtime errors (you can control this with showRuntimeErrors).
In Lua, divide by zero is not an error.
And, in any case, the issue was that although an error had occurred (and a message was logged) and the execution of that Lua context (the listener) had stopped, there was no way to know this logically in the rest of the program (like other errors it was logged to the Corona Console). A print statement after the location of the error does indicate whether the execution of the Lua context has stopped or not. A print statement appearing after a divide by zero demonstrates that is it not an error. The issue has never been that runtime errors were not occurring when they should, the issue was that an error dialog wasn't being displayed if they occurred in a network listener and that an unhandledError listener didn't work there either.
I would also council that paying attention to what's in the Corona Console while developing an app pays dividends. Errors and warnings are highlighted or you can search for "error" or "warning" if you have a lot of console output of your own (on Mac, errors also appear in the drop-down menu below the main console window). If you have suggestions for ways to make the Corona Console more useful/usable, please let me know.
Thanks Perry. Is try... catch... finally... design pattern ever going to be in the SDK?
This is especially useful for operations that can error like disk IO and network IO. At the moment Lua throws an error and code execution stops which can be problematic.
For example, in my game players can load other players cities. This requires downloading a large 2D array where each element is a varying length CSV. I crunch the data to the absolute minimum to keep bandwidth down. If there is ever an error in this process the callback stops execution and leaves a zombie-state.
With a try...catch I can handle the error and either try the download again, prompt the user and/or restore previous state.
Community Forum Software by IP.Board