Skip to main content
O
OMA2k
Inspiring
October 4, 2013
Question

Is it possible to prevent an AIR application from halting execution on minor errors?

  • October 4, 2013
  • 2 replies
  • 3046 views

AIR's error messages on runtime are very useful when developing and debugging an application, but the problem is that even on final production releases, errors halt the application as well.

Once an application has been compiled as final release (IPA or APK), errors should not halt an application. At least not simple errors such as a null variable.

For example, take this code:

import flash.text.TextField;

var tfTest:TextField = new TextField();

var appendedText:String = ' World';

tfTest.text = 'Hello';

tfTest.appendText(appendedText);

addChild(tfTest);

This just makes the sentence "Hello World" appear in the screen. But imagine if the contents of appendedString came from a server, and for some reason the server outputted "null" at some time. That would cause the application to halt. Why? Just the lack of a string shouldn't halt the application!

Try running this code:

import flash.text.TextField;

var tfTest:TextField = new TextField();

var appendedText:String = null;

tfTest.text = 'Hello';

tfTest.appendText(appendedText);

addChild(tfTest);

If appendedText is null, then AS3 execution will halt at the tfTest.appendText() call, so the text field won't be even added to stage.

Ideally, I think we should at least get the word "Hello", even if the other word is null. That's better than halting the app so we don't get ANYTHING AT ALL.

This is just a very simple example, but I hope you get the point. Why should the app halt for such a unimportant reason? It's just a text string! If it's null, then don't append anything and carry on with the app execution! Don't halt the execution of the entire app (which makes the app unusable) just for a null variable!

I know maybe someone will say that I should check all variables for null before using them, and I usually do that, but there's some instances where I maybe never thought about the possibility of a null value, or I simply forgot to check one of the many variables in my app. And it's very annoying to get that behaviour in an app which is in the App Store, because it can make an app look "crashed". And everything could have just been avoided if the app just kept executing despite that missing string.

If execution didn't halt, that missing string would have been a very minor bug (just some missing text) instead of a CRITICAL BUG WHICH MAKES THE APP NOT WORK AT ALL!

So as you can see, it makes a BIG difference.

Halting the app with an error message during development is useful, but it doesn't make sense to halt execution in a production app, where a halted app just annoys the user, who can't do anything about it and can't see the error message anyway.

I can understand halting on "fatal errors", but just appending a null string is hardly a fatal error!! That shouldn't stop executing the app.

So is it possible to have a less picky error system when an app is compiled as release so execution is not halted in unimportant errors?

This topic has been closed for replies.

2 replies

A
Apocalyptic0n3
Inspiring
October 4, 2013

It shouldn't halt application execution, only that specific series of executions. The next interaction from the user, assuming the halting of that series of executions does not prevent further interaction, should still happen correctly. The halting of all app execution is restricted to debug mode, not release mode. And even in debug mode, you can push through it manually by hitting the "resume execution" button in the IDE

O
OMA2kAuthor
Inspiring
October 4, 2013

Thanks for your answers.

@Gaius Coffey: I know that putting addChild before the problematic line would "solve" the problem in the code above. But that was just a tiny example to get my point cross, not a real problem. The problem lies with longer and more complex codes.

@ApocalypticOn3: Well, yes, maybe I didn't use the right words. I know that doesn't really halt an application completely, but just halting execution in a block of code is bad enough. Why? Imagine that for some reason block code execution is halted early in a function because a non-important problem, but that causes that a lot of addEventListeners, addChilds and other stuff is NOT executed, so the user gets a non-responsive UI. That's a BIG problem, which could have been a really tiny problem instead if execution carried on despite of a null variable being called.

I've also had apps appear to have crashed (even if they really didn't) because I was showing a "Loading" overlay which prevented app use during load, and since some block code execution halted, the overlay never disappeared (since the removing of the overlay is made at the very end of the block, after everything else is done), so it appeared as if the app had crashed, even if internally the AIR app was still running fine.

That's my point. The only solution is checking aaaall variables every time (which I try to do, but sometimes I miss something out), or maybe making sure that "important" stuff is executed first? (such as the solution @Gaius Coffey suggested). That's really annoying. Why should I have to care about the order of execution to do stuff such as adding Event Listeners, adding elements to stage, etc.? Why do I have to check for null EVERY time?!

Error checking when executing a final production release version should be a lot less strict. Strict error checking is useful only for developers during development and debugging. But end-users don't benefit from such a strict error checking at all! On the contrary, they just get a non-working app for stupid reasons (a missing string).

So isn't there any way to turn that block code halting off when the app is compiled as final release?

A
Apocalyptic0n3
Inspiring
October 4, 2013

What you suggest really isn't possible. AS3 uses a fairly strict linear execution model. What happens on one line affects what happens on the next line and so on and so forth. For that reason, the runtime assumes that what happens on one line is needed for what happens on the next line (generally a good assumption to make). By that logic, if there is an error on line 4 and line 5 needs what happened on line 4, an error/unexpected result is likely to happen on line 5. The Flash runtime halts execution purposefully to prevent further errors. By halting execution, it keeps the error with just the single object. If it kept going, you could have an infinite number of objects with unexpected/improper values.

And a null object reference is not a minor error. Sure, it is minor when you're trying to set text and the value is null. But at other times, a null reference can screw up the internal workings of an entire object. Think about the addChild()/addElement() methods. Every DisplayObject you pass to those affects every object passed to them in the past and in the future, as well as the entire DisplayList chain up to the main application. Passing a null reference to one of those could have negative effects on every single object on the stage.

Yes, that is an extreme case. But the entire basis of good development is to hope for the best, plan for the worst.The runtime can't assume a null reference isn't a big issue. It can't assume that you built your code to handle untold errors. It has to assume that an error is going to have dire consequences for the rest of the application. I know you'll suggest they could ignore null references on standard datatypes (like String and Number), but those datatypes are used for much more than just setting elements on the stage. Most internal settings, settings that could affect not only your app but the rest of the system if Adobe did not sandbox correctly, are set using numbers and strings. If Adobe allowed invalid values to be set, it could be dangerous for the device.

Really, this is not on Adobe or the runtime, it is on you. It is on us. We, the developers, need to plan for such possibilities. It is no different than forgetting to validate user-provided data or not planning for all the possible situations an event handler might be called. This is part of your job in creating a quality application. Adobe's responsiblity is to create a secure and usable SDK/Runtime, not to make your job easier.

G
Gaius Coffey
Legend
October 4, 2013

Hi,

I don't think it is halting the application just discontinuing the function call in which the error occurs.

This, for example, would display your field even if there was a null value:

import flash.text.TextField;

var tfTest:TextField = new TextField();

// Move addChild up to before the problem null pointer

addChild(tfTest);

var appendedText:String = null;

tfTest.text = 'Hello';

tfTest.appendText(appendedText);

//addChild(tfTest);

G

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices