UNHANDLED ERROR BEHAVIOUR? PLEASE ADVISE

Solar2D General Questions/Discussion
#1

Sorry if newbie question, but here it goes:

  • using Corona Simulator, late build (2014.2248), sublime and CE plugin, Mac OS

I found that if I have a runtime error like trying to invoke a nil function or resolve a nil var, especially inside of a callback stack, the function just fails and returns without raising an evidence of an error!

I set up an unhandled error listener, i.e. 

       Runtime:addEventListener(“unhandledError”, myUnhandledErrorListener)

and that made no difference, in fact it is never called. I followed the relevant tutorial and can’t get that event listener to fire . 

I find that debugging stupid little code errors is a pain since my callbacks just stop and return when they hit a violation, e.g. print (foo) where foo us undefined.

What am I doing wrong? I want my app to blow up, so I can fix the bug, not to keep going silently!!

very frustrated, would appreciate any help.

THANKS!

#2

I have seen this issue as well. Any updates from Corona Staff? Its especially a problem when debugging on an android device. The error appears in logcat but won’t fire the unhandledError event.

#3

Nothing yet. In fact, using CE/Sublime, on Mac, using Coronal Simulator, during development…if I make a coding error and run (like a null pointer, etc), the whole thing just hangs, nothing to show you what’s wrong. I miss the good old days with any other environment, where a null pointer throws an exception, or a seg fault, or anything. Seems like here you have to code really well or add a print statement every 2 lines!

Out of all my desired improvements, this has to be #1 =(

#4

Corona Simulator will stop on error by default. If you run code on a device, the error can be viewed in the console (if connected) but doesn’t stop on an error. You can turn on error popups on a device by adding the following to config.lua:

application =
{
showRuntimeErrors = true,
}

You can find the information here:

http://docs.coronalabs.com/daily/guide/basics/configSettings/index.html#runtime-errors

We are considering making the display of runtime errors on a device the default mode for debug builds.

#5

Tom, by enabling showRuntimeErrors will it fix the soft fails issue we are talking about?

#6

The showRuntimeErrors parameter in the config.lua file only affects device builds. There is a “Show Runtime Errors” in the Simulator’s preference menu for showing Simulator runtime errors. This option is on by default. You should check to see if it’s enabled. 

#7

Tom, to be clear, the issue that we are having is that the code is failing on both simulator and device, consistently with certain errors, and its not throwing any error event. The error appears in the logcat and in the simulator terminal logging, but for some reason does not activate the unhandledError call.

#8

I just tested this with an Android build and I do get an error listener callback and I get a popup when I have the config.lua statement and return false in the error handler.

The key is making sure the Runtime code to listen for errors occurs the first thing in your main.lua. If you define the Runtime at the end of your main.lua and your runtime error is before that, it won’t catch the error because it hasn’t had  a chance to run. (Most device errors occur after the first pass through main.lua so this is not normally an issue.)

I’m assuming this is the issue but since you didn’t provide all your code, it’s only a guess. This is why we ask for complete code projects to avoid the extra time it takes to guess what your code is doing.

I do see that we don’t mention that the runtime code needs to be defined first thing in the main.lua file so I’ll update the guide to make that point clear.

#9

hmmm, the runtime error listener only triggers with ‘easy’ errors…I found that if you have a typo, lets say, in an argument to a widget  or display object constructor, the system fails catastrophically and totally silently and it’s a real $%&!@ to find the error. I found that I am less efficient coding in this environment than in any other framework/language ever! I’m very surprised that others don’t share the same frustration, I still think I must be missing something obvious? I’ve never used so many print() statements in my life! =(

example:

local foo = display.newLine(0, 10, 0, badVar/2)

(where badVar is undefined because I meant to use a defined ‘goodVar’). The runtime unhandled error listener will not trigger. This is inside a scene, whereas the runtime listener was set up on the beginning of main.lua

thoughts?

#10

Strict.lua is your friend (for undefined variables or typos)

Strict.lua: http://metalua.luaforge.net/src/lib/strict.lua.html

More info: http://lua-users.org/wiki/DetectingUndefinedVariables

#11

I have seen this issue as well. Any updates from Corona Staff? Its especially a problem when debugging on an android device. The error appears in logcat but won’t fire the unhandledError event.

#12

Nothing yet. In fact, using CE/Sublime, on Mac, using Coronal Simulator, during development…if I make a coding error and run (like a null pointer, etc), the whole thing just hangs, nothing to show you what’s wrong. I miss the good old days with any other environment, where a null pointer throws an exception, or a seg fault, or anything. Seems like here you have to code really well or add a print statement every 2 lines!

Out of all my desired improvements, this has to be #1 =(

#13

Corona Simulator will stop on error by default. If you run code on a device, the error can be viewed in the console (if connected) but doesn’t stop on an error. You can turn on error popups on a device by adding the following to config.lua:

application =
{
showRuntimeErrors = true,
}

You can find the information here:

http://docs.coronalabs.com/daily/guide/basics/configSettings/index.html#runtime-errors

We are considering making the display of runtime errors on a device the default mode for debug builds.

#14

Tom, by enabling showRuntimeErrors will it fix the soft fails issue we are talking about?

#15

The showRuntimeErrors parameter in the config.lua file only affects device builds. There is a “Show Runtime Errors” in the Simulator’s preference menu for showing Simulator runtime errors. This option is on by default. You should check to see if it’s enabled. 

#16

Tom, to be clear, the issue that we are having is that the code is failing on both simulator and device, consistently with certain errors, and its not throwing any error event. The error appears in the logcat and in the simulator terminal logging, but for some reason does not activate the unhandledError call.

#17

I just tested this with an Android build and I do get an error listener callback and I get a popup when I have the config.lua statement and return false in the error handler.

The key is making sure the Runtime code to listen for errors occurs the first thing in your main.lua. If you define the Runtime at the end of your main.lua and your runtime error is before that, it won’t catch the error because it hasn’t had  a chance to run. (Most device errors occur after the first pass through main.lua so this is not normally an issue.)

I’m assuming this is the issue but since you didn’t provide all your code, it’s only a guess. This is why we ask for complete code projects to avoid the extra time it takes to guess what your code is doing.

I do see that we don’t mention that the runtime code needs to be defined first thing in the main.lua file so I’ll update the guide to make that point clear.

#18

hmmm, the runtime error listener only triggers with ‘easy’ errors…I found that if you have a typo, lets say, in an argument to a widget  or display object constructor, the system fails catastrophically and totally silently and it’s a real $%&!@ to find the error. I found that I am less efficient coding in this environment than in any other framework/language ever! I’m very surprised that others don’t share the same frustration, I still think I must be missing something obvious? I’ve never used so many print() statements in my life! =(

example:

local foo = display.newLine(0, 10, 0, badVar/2)

(where badVar is undefined because I meant to use a defined ‘goodVar’). The runtime unhandled error listener will not trigger. This is inside a scene, whereas the runtime listener was set up on the beginning of main.lua

thoughts?

#19

Strict.lua is your friend (for undefined variables or typos)

Strict.lua: http://metalua.luaforge.net/src/lib/strict.lua.html

More info: http://lua-users.org/wiki/DetectingUndefinedVariables