06 March 2013
Runtime Error Handling
As those of you who build for Android have already noticed we’ve made changes to the way we report errors. It was necessary to do this on Android first because improved run-time error handling was a prerequisite to getting the custom Android permissions feature implemented.
Now it’s time for the rest of the platforms (iOS and simulators) to catch up and implement run-time error handling too. We’re also rolling out the unhandled error listener, which can be used to trap errors which would otherwise trigger the Runtime Error pop-up. It can’t fix your run-time errors but it can hide them.
This is an example of how the run-time error handler is defined:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
local function myUnhandledErrorListener( event ) local iHandledTheError = true if iHandledTheError then print( "Handling the unhandled error", event.errorMessage ) else print( "Not handling the unhandled error", event.errorMessage ) end return iHandledTheError end Runtime:addEventListener("unhandledError", myUnhandledErrorListener) |
The event table passed to the listener has errorMessage and stackTrace parameters which are respectively, the error message that resulted from the error and the stack trace at the point of the error. Returning true from the listener will suppress the pop-up alert message and allow the app to continue running. Returning false will show the pop-up and abort the app (the default action if the unhandledError listener is not implemented in your code) but you’ll have the opportunity to do things like log application state to the console.
The major change you’ll see in the next daily build is a pop-up message when a run-time error occurs. Adding the above mentioned unhandledError listener is needed if you want to trap and suppress the pop-up message and app aborting.
The above feature should be available starting with daily build 1044 and above.
Andreas
Posted at 01:46h, 07 MarchThis is fantastic! This already did help me with some android versions of my apps and to have this now for iOS & the simulator is most helpful.
Thanks!
Stephen Lewis
Posted at 08:51h, 07 MarchAny tips or best practices on what to do with an error captured by the listener when running on a released app? Obviously on a development build I want to see the error message and as much info as I can get to track down the problem, but a 9-year-old running a release version of my game isn’t going to know what to do with, or care, about some esoteric error message. Most likely I want to suppress the message and prevent the crash. What’s a good way for me to get info about the error while still providing a reasonable customer experience?
ojnab
Posted at 12:12h, 07 MarchThis is great!
@stephen. you could log the error / stack trace with the analytics system.
JesterXL
Posted at 12:19h, 07 MarchLove this!!!
jufjannie
Posted at 15:01h, 07 MarchWouldn’t it be more logical to have the default state be that is on. That it blocks the pop ups and that you can turn it on when you are in debug mode?
Now users can get a pop up that interrupts the app when the programmer forgets to put this in his code.
If you want to update an app you will have to add this code to the files so it doesn’t start popping up.
This creates extra work. If it defaults to intercepting and not showing the pop up, nothing changes for the end user and programmers who don’t care.
Now it is being forced upon us.
As stated in a previous article on this by the writer. Not all run time errors crash the app or cause any inconvenience. Now they do.
Simon Fearby
Posted at 03:17h, 11 AprilThis helps me detect a stack overflow but unfortunately does not give me more info?
I have working code that was working in Jan 2013 but a newer corona build has broken the widget cant text input destroy code. I rolled back my code to the Jan 2013 code but the new corona crashes
Maybe I need to roll back to an older corona?
——–
Handling the unhandled error ?:0: stack overflow
2013-04-11 20:06:25.342 Corona Simulator[1339:707] Runtime error
?:0: stack overflow
stack traceback:
[C]: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
…
?: in function ‘_cachedRemoveSelf’
?: in function ‘removeSelf’
?: in function ‘remove’
…re/AppsSVN/Removed/widget_candy.lua:1202: in function ‘_RemoveWidget’
…re/AppsSVN/Removed/widget_candy.lua:593: in function ‘destroy’
…AppsSVN/Removed/recipecalscreen.lua:1847: in function ‘cleanUp’
…m Software/AppsSVN/Removed/main.lua:87: in function ‘loadScreen’
…m Software/AppsSVN/Removed/main.lua:110: in function ‘onRelease’
…com Software/AppsSVN/Removed/ui.lua:90: in function
?: in function
greg
Posted at 17:01h, 02 Septemberso re returning true or false.. the doco has:
“If true is returned from the listener for unhandledError then the error is suppressed and application execution will continue. Returning false (or nothing) from the listener will allow the runtime error to be reported to the user and the the application to terminate.”
So does this imply if you return false (or nothing) the application will continue to behave exactly how it would have if you didn’t implement the handler? So if you had some error in a listeners that was occurring but not crashing the app and the user could still play, then after implementing this error handler system it would be the same, but with the advantage of you had a chance to print it out (or log it to flurry for example)
This being the case, then the safest approach would be to return false (or nothing) correct?