How To Use Runtime Error Handler?

Currently testing out an app and it gets error from a scenario like this:


 

item.tween = transition.to(item,{time=500,x=500,onComplete=function()

   item.tween = nil

end})

 

 

And sometimes “item” gets removed and nilled out before this transition finishes. And we get an error. Classic problem. Obviously I need a better method of preventing this from happening. But that’s another story. I am just trying to figure out how to use the Runtime Error Handler.

 

So I have the Runtime Error Handler set up as mentioned in the recent blog post.

 

So first in the Simulator. When this error happens, first I see the Runtime Error in the Terminal like usual and then following that I see the Runtime Error Handling Listener printing out its own print statements. Excellent, seems to work on the Simulator.

 

So I then test it out on the device (an iPad3) and monitor it in the xCode Organizer Console.

The first Runtime Error shows up in the console, but never the Runtime Error Handler Listener print statements. I suppose it never executes because the app stopped at the Runtime Error? No idea.

 

I get no popups, nothing. And I tried both return true and false in the handler function. And I am using daily build 1056.

 

Am I missing something? Should The Runtime Error Handler be working on the device? Should it be printing stuff to the xCode console?

 

 

 

I see the same thing on an iPad 2.  I force a runtime error and the error is seen in the console but nothing in my error handler seems to get executed, including print statements, but more importantly, a flurry analytics event never gets fired which is how I planned on getting notified of a runtime error once the app is live in the field.  True, the crash and popup window with the error gets suppressed, as advertised, but interestingly if I keep using the app and then force the same error the app then freezes up.  

 

The error handler is pretty useless if I never get the message that there was a problem, but in some ways the current behavior is worse than simply crashing out which does at least get automatically reported as an error event in Flurry. 

I’ll pass this on to the engineers.

As with most nuances in programming languages, I’ve learned to have to be thorough when deconstructing and disposing of things I’ve created. I don’t know about nil’ing a transition in progress, I can only imagine bad things that could happen. Anytime I’m about to delete an object, I cancel and related timers and transitions: local function killObject( obj ) if obj then if obj.timer then timer.cancel( obj.timer ) end if obj.tween then transition.cancel( obj.tween ) end if obj.x then display.remove( obj ) end obj = nil return true else return false end end

@BeyondtheTech, I don’t understand how your reply relates to the thread topic.  Perhaps you posted in the wrong thread by mistake?

LOL, someone sent me a private message and I thought I was replying back there.  Funny thing is the code I saw at the top of the page looked similar what he wrote to me as well.  Oops!

 

Still getting used to this forum.  It’s a little too big and spaced out for my tastes.  On my little MacBook Air, I’m scrolling all over the place.

I see the same thing on an iPad 2.  I force a runtime error and the error is seen in the console but nothing in my error handler seems to get executed, including print statements, but more importantly, a flurry analytics event never gets fired which is how I planned on getting notified of a runtime error once the app is live in the field.  True, the crash and popup window with the error gets suppressed, as advertised, but interestingly if I keep using the app and then force the same error the app then freezes up.  

 

The error handler is pretty useless if I never get the message that there was a problem, but in some ways the current behavior is worse than simply crashing out which does at least get automatically reported as an error event in Flurry. 

I’ll pass this on to the engineers.

As with most nuances in programming languages, I’ve learned to have to be thorough when deconstructing and disposing of things I’ve created. I don’t know about nil’ing a transition in progress, I can only imagine bad things that could happen. Anytime I’m about to delete an object, I cancel and related timers and transitions: local function killObject( obj ) if obj then if obj.timer then timer.cancel( obj.timer ) end if obj.tween then transition.cancel( obj.tween ) end if obj.x then display.remove( obj ) end obj = nil return true else return false end end

@BeyondtheTech, I don’t understand how your reply relates to the thread topic.  Perhaps you posted in the wrong thread by mistake?

LOL, someone sent me a private message and I thought I was replying back there.  Funny thing is the code I saw at the top of the page looked similar what he wrote to me as well.  Oops!

 

Still getting used to this forum.  It’s a little too big and spaced out for my tastes.  On my little MacBook Air, I’m scrolling all over the place.