Having the error message with the file and line number when the app crashes is very useful in development. But I think is very bad that a user can see the file (specially the path) and the line of the error.
However, the only alternative that I can find is making use of the “unhandledError” event and return true. But this can won’t abort the app and it’ll leave it in a bad state. Can I have the app aborted without showing the file/line of the error?
Thanks.
You can, using os.exit()…however this isn’t allowed on iOS. If it happened during review it would be rejected.
On desktop builds, I use the unhandled runtime error listener to display my own message with an error code, and then use os.exit() to shut down the app.
Thanks for the response, yeah I saw about os.exit() but it’s what you mentioned: it’s not allowed on iOS, so I’ll need a cross device solution.
Nick just suggested the solution.
Directly os.exiting is not allowed in iOS, but if you pop-up a message first then exit when they click OK, you should be fine.
So exiting after showing a popup would pass review?
The documentation mentions “This is a low level Lua call that should not be used on any platform.” Would it be ok to use in this case then?
Thanks
Nobody can tell you for sure your app will pass review.
I’m saying, gracefully handling the abort case is more likely to pass review and Nick gave advice on how to handle it gracefully.
Note - I actually suggest: https://docs.coronalabs.com/daily/api/library/native/requestExit.html
Dang… I posted (https://docs.coronalabs.com/daily/api/library/native/requestExit.html), but then saw it is not supported on iOS.
So I’d stick with os.exit()
Also, I should have said this earlier, but the real question here is why are you getting errors? You should be fixing that instead of trying to handle it and fail gracefully.
It really is NOT a good idea to submit apps to the store(s) when you know they throw errors.
I disagree with that being the real question. I’m not saying that I have errors, and I won’t submit my app with known errors. What I don’t want to do is submit it without being prepared for the case in which an unexpected runtime error happens. It’d be a very bad idea to think that it won’t happen just because it wasn’t caught during testing.
What I think the issue is, is that there’s no good way to let the app handle an unexpected runtime error, you either have the option of showing the user a stack trace that includes the path of your file, or leaving the app in a bad state that’s going to confuse the user and may produce unexpected behavior. Both options seem really bad to me.
In the unfortunate event that an unexpected error happens in runtime, I think the better option would be to gracefully let the user know (with no stack trace or similar) and let the app close itself.
I see where you’re going with this.
Then you’ll need to use the technique Nick suggested. Assuming you don’t crash/encounter an error during the review you should be fine.
Since errors should be non-existent or rare that should be a non-issue.
-Ed
The native.requestExit() is the preferred way to exit a non-iOS app, which based on iOS users expectations an app should never exit. This means that native.requestExit() can be safely called on iOS and it will be ignored giving you a cross-platform solution.
However in the case where you caught an exception and need to force an exit, you would probably in that case need to determine the platform and call os.exit() if you’re on iOS, tvOS and potentially macOS. But on Android, you should still try and use native.requestExit().
Rob
Yeah that makes sense, thank you very much Ed and Rob.
You can, using os.exit()…however this isn’t allowed on iOS. If it happened during review it would be rejected.
On desktop builds, I use the unhandled runtime error listener to display my own message with an error code, and then use os.exit() to shut down the app.
Thanks for the response, yeah I saw about os.exit() but it’s what you mentioned: it’s not allowed on iOS, so I’ll need a cross device solution.
Nick just suggested the solution.
Directly os.exiting is not allowed in iOS, but if you pop-up a message first then exit when they click OK, you should be fine.
So exiting after showing a popup would pass review?
The documentation mentions “This is a low level Lua call that should not be used on any platform.” Would it be ok to use in this case then?
Thanks
Nobody can tell you for sure your app will pass review.
I’m saying, gracefully handling the abort case is more likely to pass review and Nick gave advice on how to handle it gracefully.
Note - I actually suggest: https://docs.coronalabs.com/daily/api/library/native/requestExit.html
Dang… I posted (https://docs.coronalabs.com/daily/api/library/native/requestExit.html), but then saw it is not supported on iOS.
So I’d stick with os.exit()
Also, I should have said this earlier, but the real question here is why are you getting errors? You should be fixing that instead of trying to handle it and fail gracefully.
It really is NOT a good idea to submit apps to the store(s) when you know they throw errors.
I disagree with that being the real question. I’m not saying that I have errors, and I won’t submit my app with known errors. What I don’t want to do is submit it without being prepared for the case in which an unexpected runtime error happens. It’d be a very bad idea to think that it won’t happen just because it wasn’t caught during testing.
What I think the issue is, is that there’s no good way to let the app handle an unexpected runtime error, you either have the option of showing the user a stack trace that includes the path of your file, or leaving the app in a bad state that’s going to confuse the user and may produce unexpected behavior. Both options seem really bad to me.
In the unfortunate event that an unexpected error happens in runtime, I think the better option would be to gracefully let the user know (with no stack trace or similar) and let the app close itself.