Daily Build 1051- 1054 - Annoying Popups With Errors

Solar2D Daily Builds and Public Releases
#21

@krystian6, take a look at the following.  You can find the error handling code that would disable the popups:

 

http://www.coronalabs.com/blog/2013/03/06/run-time-error-handling/

 

http://www.coronalabs.com/blog/2013/03/13/wednesday-faq-runtime-error-listener/

 

BTW, I’m assuming that this code would be placed in main.lua only, and I don’t need to add them locally in each individual lua modules.  If I’m mistaken, I’d like to hear about it.  (I need to download the daily build 1044 or later to get it to work, and I’m still using 1041.  It’s probably time for me to download the latest…)

 

Naomi

 

Edit:  We need build 1047 or later to enable unhandled error listener.

#22

Hi @krystian6,

Thanks for the feedback. We’re aware that this has irritated some users and we’re looking into resolving it a.s.a.p. The intention is to alert developers to code errors if they’re not using or currently viewing the Terminal/console. However, I understand that every developer codes in their own unique way, and this popup is not a desired feature for all.

To all reading this, if you have any specific and constructive comments on how you “want this feature to work”, it will help us resolve it soon according to the needs of the overall Corona developer community. Please post your comments in this thread and I’ll keep track of them.

Thanks,

Brent Sorrentino

 

#23

Hey, Brent, I’m definitely setting the unhandled error listener to true so that I don’t have to see the popup.  

 

I would like it if we can simply set a flag to true or false at the top of main.lua to decide if we want to see the runtime error without console/terminal.  Setting it to true would feel more intuitive if we want the feature activated, and false if we don’t want the feature activated.

 

And if we choose to activate the feature, developers could further refine it for their own use, including the function like the unhandled error listener.

 

Naomi

#24

@Brent Sorrentino A simple solution: Add an option in File -> Preferences -> Error popups   ON/OFF
 

#25

@Naomi, @vovasoft,

Both of these ideas sound reasonable at first thought. Expanding on this, if a user does want to use the error popups, do you have a preference on how they behave? For example, what is displayed in the popup itself? Options (buttons) below? Or perhaps something closer to a “Growl-like” notification that doesn’t need confirmation at all? Just curious on your thoughts…

Brent

#26

@Brent Sorrentino I think there is already Corona simulator output and people use it when they are testing an app. If an error occurred and output window is minimized then you should bring it to front. The simulator should be as simple as possible and please remove that annoying error popup.
@Naomi solution involves people to change all projects.

#27

Naomi’s solution wouldn’t neccessarily require changing all projects. If the default was false it would require nothing on the part of anyone or any project. However I see the problem in that Corona Labs may be doing this for people perhaps that are not aware of the terminal or are confused on how to see debug information. The terminal is one thing but it’s more involving when you want to do so on a device and need xcode or adb.

 

I understand boths sides (if my thoughts on Corona are even close to their reasoning). However I feel this should be an opt-in sort of functionality rather than an opt-out. Perhaps just setting debug=true in the projects config file or something. If not present it defaults to false and everything is as it was before adding the pop-ups.

#28

@Brent, I think your question would need to be answered by the developers who would want to use this option.  Since I’ve been happy with the way I debug my code using console/terminal with print statements, I haven’t really spent time thinking about how it can be improved.  That said, terminating the app after any and all runtime errors caught by the popup is a bit too much.

 

I had a case where I show Facebook friends on my app, with each of the friends profile pix displayed using display.loadRemoteImage function.  Well, some of the friends’ profile pix may not always get displayed quickly.  In fact, occasionally, event.target makes it to the app much much later even though I’ve already moved on to another scene.  When that happens, I have a flag (global variable) that tells event.target to be removed and nil’ed instead of being inserted to display.newImageRect (and hopefully this does clear out the event.target from memory and no lingering items from already closed scene to remain.)  However, with this runtime error popup thing, my app seemed as if it got terminated out of blue for a reason totally unrelated to what was happening with the app at the time.  In a case like this, I’d rather have the app go on without terminating.  I haven’t seen this latency issue to cause any problem with my app until this popup was activated.

 

@vovasoft and @Anderoth, I like the simple solutions you are suggesting.

 

Naomi

#29

Simple checkbox in preferences to enable/disable this feature would be great.

#30

+1

#31

 

+1

#32

I disagree on the checkbox. That would be a global setting and I feel this needs to be on case by case basis per project. Some projects I would like this on, while others no.

#33

I would prefer it in the config.lua file or near the top of your main.lua file over a global checkbox as well, but it definitely needs to be toggle-able. 

#34

At the moment there are two types of error popups:

  1. on Device
  2. in Corona Simulator

There should be two options in **File -> Preferences ->

  1. Error popups in simulator ON/OFF**     (You will still see the error in Corona simulator output window in both cases)
    2. Error popups on device ON/OFF         (When ON there should be a popups = true in config.lua to see popups. )

 

 

#35

@voasoft

Why do we need a checkbox AND code? I can see you really want checkboxes badly.

 

However again, I disagree. Nothing about how my code works is currently in “Preferences” and I prefer it not to be going forward. Keep in it in the code were all options currently are. Do not mix and match how we do things.

#36

@Anderoth checkboxes are very simple.
 

Nothing about how my code works is currently in “Preferences”

Yes but I’m talking about popups in simulator. Why should I change code in my projects to configure the simulator popups ?
And I agree with @BeyondtheTech that popups on devices should be “toggle-able” in config.lua.
 

#37

Agreed. If you want a check-box to allow/disallow them in simulator and the config controls the device. Fine by me.

 

The biggest point of my first post is this should all be opt-in. If it’s opt-in, then no worries, everything goes back to the way it was unless you want to see them.

#38

Although I disagree with @BeyondtheTech [why would anyone want to mix external tool setting in the code??], I can’t see why wouldn’t you just include the checkbox in the preferences + add possibility to control simulator from within the code. It’s not like it’s going to dramatically change your testing process :wink: .

#39

We’ve been listening to your feedback and hope we’ve come up with a scheme that works well for both newcomers to Corona and for the old hands who know what they’re doing.  It allows control at both the Simulator and application levels.

There is now a setting in the Simulator preferences called Show Runtime Errors which defaults to on and which causes runtime errors to always pop up when the application is run in the Simulator.  If you don’t like this or it doesn’t fit with your workflow you can turn it off.  It’s global for all applications.

We also added a setting to config.lua that can be used to control the display of errors in applications running on the device.  It’s called showRuntimeErrors and takes a boolean value ( true or false ).  It defaults to off (false)_.  _If you explicitly set showRuntimeErrors to false in your config.lua that will override the preference in the Simulator for that application (to turn it off, just comment it out rather than setting it).  Remember that turning off the display of errors doesn’t mean they aren’t happening and changing the way your app works, almost certainly in bad ways.  We want you to know about errors because they are causing your users’ mileage to vary and diminishing their enjoyment of your apps.

Note that even if you turn off the display of runtime errors, the unhandledError listener still gets called but it doesn’t matter what you return from it, the popup error is never displayed.  This allows you to implement your own error reporting if you want to.  Having an  unhandledError  listener is completely optional.

In writing this I’ve realized that I’ve neglected the documentation for this so I better get to that.  Let me know what you think of the new scheme.

#40

A very good choice. Thank you @Perry Clarke.