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:
local function myUnhandledErrorListener( event )
local iHandledTheError = true
if iHandledTheError then
print( "Handling the unhandled error", event.errorMessage )
print( "Not handling the unhandled error", event.errorMessage )
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.