makes sense 
Regarding your question under the link. From my experience you can execute code just fine in handler scope. I was able to handle native alert and it’s buttons (however no idea what will happen when trying to call outer code). The reason I’d rather close app is because runtime errors corrupt application functionality completely.
update - actually logging errors to Flurry, but I have found that the error handler that grabs the error and logs it still doesn’t have file names / function names 
For example I see this in flurry for a stack trace:
stack traceback: [C]: ? ?: in function ‘?’ ?: in function <?:1525> ?: in function ‘dispatchEvent’ ?: in function <?:569> ?: in function <?:218>
Strange, ‘?’ are in places where should be file or function name, it must be something with Corona itself. Have seen thread recently with this kind of problem. Can someone from Coronalabs help?
Coronalabs feedback would be great - especially if others have seen the event hander working whereby filenames etc are included…
FYI my code re event handler code (cut down to key bits):
local function myUnhandledErrorListener( event ) analytics.logEvent( "Error", { errorMessage=event.errorMessage, stackTrace=event.stackTrace } ) end Runtime:addEventListener("unhandledError", myUnhandledErrorListener)Maybe I’m having a Deja Vu, but I could swear I’ve answered this a couple of times in other posts.
Compile byte code in your device app won’t have any data symbols, module filenames, etc. for you to use.
Thanks Rob. It was wishful thinking to hope the error handler case might give a better result than looking at the console output on Xcode
Rob, you’ll receive even more of those request until this is fixed. Having an unhandler error callback is useless if we can’t get a meaningful stacktrace to log on our servers. And there is nothing we developers can do besides spam every single function with possibly unneeded print statements.
You guys have access to the Lua compiler’s source code, right? It should be a piece of cake to remember the name for every function entered.The stack already contains line numbers - how difficult could it be to also include the function name at least? Just a few lines of code on your behalf will be a life-saver for your clients. Having access to the compiler, you could even put the competion to shame by also including the primitive values with which the functions are called
Please elaborate, what’s hindering you from doing that?
The part about compiling to byte code… that’s whats hindering us from doing that. Symbols are stripped and replaced with very small byte codes to represent them. White space like line numbers go away. Its one long string of bytes. There are no lines to reference.
Rob
Thanks for the quick response, Rob!
About this byte code:
-
Can it be changed to include debug data in future versions or it needs to be backwards-compatible? It obviously has some notion of stack/functions/jumps/gotos given that some mangled stack trace is still generated, why can’t this be improved?
-
How can the simulator output a perfect stack-trace upon error and the device can’t? If it is interpreted instead of compiled, that means the compiler is problematic. Other byte-code compilers like Java’s and C#'s can still generate debug data, why isn’t this possible with Lua/Corona?
Sorry for the annoying questions but this is really bugging me. I’m on the verge of writing an automated tool to append stack-trace data on every function of a project’s source code. But I somehow feel this will be more elegantly approached on the compiler’s end.
It might not be clear but debug symbols are only stripped from the compiled Lua code when doing “distribution” builds. In Corona terms this means, on the iPhone, using a Code Signing Identity whose name begins with “iPhone Distribution:” and for Android it means using a keystore with any name other than “Debug” (I understand these are arbitrary definitions but we had to go with something).
This means you can’t submit unstripped code to the app stores but you can run on the device with full debug info (just use an appropriate cert when building).
Just so I understand correctly, is the request to be able to distribute apps via the app stores with debug info in them? Or were the conditions under which stripping occurs unclear?
My 20c worth. From a user requirement point of view re a development platform my main point would be:
“Ability to quickly/efficiently track down bugs in general”.
The thing that sticks out is there is some functionality that you can’t test on the simulator, but when testing on the device you hit the symbols issue. This would seem to imply the need for the simulator to simulate all functionality (including plugins etc) to meet the user requirement. What do you think? (i.e. just from a “idealist” point of view) i.e. should there be more focus on the simulator? (I’m not sure of the answer, just asking the question)
As I said, you *can* run with debug symbols on the device, you just can’t distribute to the app stores with debug symbols.
sorry Perry - I misread the thread (was just skimming through forum responses) - thanks for pointing this out - I’ll start changing my process when testing on the device based on the Code Signing Identify…thanks again
We’ve added a build.settings parameter to allow distribution builds with debug info in them to be made. It’ll be available in Daily Build 2014.2221 and later.
This is the documentation …
Normally distribution builds of an app (those intended for app stores) have Lua debug info stripped from the compiled code while development builds are not stripped. Generally stripping debug symbols is preferred for distribution because it reduces app size and provides a small performance gain but the tradeoffs entirely depend on the type of app and how you like to do error reporting.
On the iPhone, distribution builds are made by using a Code Signing Identity whose name begins with “iPhone Distribution:” and on Android they are made by using a keystore with any name other than “Debug”.
Sometimes it can be useful to have debug symbols available in distribution builds of your app. This means you get more detail in stack traces and runtime error messages. The neverStripDebugInfo setting can be used to turn off debug symbol stripping altogether. In theory, there’s no reason why an app built with this setting could not be submitted to an app store but policies vary and there are no guarantees. The debug info may reveal details of your app that you would prefer to remain proprietary.
settings = { build = { neverStripDebugInfo = true } }Perry, that’s great news! This option is exactly what I was looking for - leaving debug symbols in for distribution builds. The bugs we face are sometimes hard to reproduce, both in simulator or by manually testing debug device builds, so the only option we had was verbose logging on the user devices in the wild. Thanks a lot!
Has this been added to enterprise as well? It is not working for me on 2223
Rob, you’ll receive even more of those request until this is fixed. Having an unhandler error callback is useless if we can’t get a meaningful stacktrace to log on our servers. And there is nothing we developers can do besides spam every single function with possibly unneeded print statements.
You guys have access to the Lua compiler’s source code, right? It should be a piece of cake to remember the name for every function entered.The stack already contains line numbers - how difficult could it be to also include the function name at least? Just a few lines of code on your behalf will be a life-saver for your clients. Having access to the compiler, you could even put the competion to shame by also including the primitive values with which the functions are called
Please elaborate, what’s hindering you from doing that?
The part about compiling to byte code… that’s whats hindering us from doing that. Symbols are stripped and replaced with very small byte codes to represent them. White space like line numbers go away. Its one long string of bytes. There are no lines to reference.
Rob
Thanks for the quick response, Rob!
About this byte code:
-
Can it be changed to include debug data in future versions or it needs to be backwards-compatible? It obviously has some notion of stack/functions/jumps/gotos given that some mangled stack trace is still generated, why can’t this be improved?
-
How can the simulator output a perfect stack-trace upon error and the device can’t? If it is interpreted instead of compiled, that means the compiler is problematic. Other byte-code compilers like Java’s and C#'s can still generate debug data, why isn’t this possible with Lua/Corona?
Sorry for the annoying questions but this is really bugging me. I’m on the verge of writing an automated tool to append stack-trace data on every function of a project’s source code. But I somehow feel this will be more elegantly approached on the compiler’s end.