It's time for NaN to throw errors
We've all experienced it. You're trying to position or size something and it draws all wacky. You're not sure why, but eventually you figure out that one of the values is NaN. The Flash runtime does absolutely nothing to help you solve this problem, but it really should.
By contrast, if you try to run operations on something null, you get a #1099 that tells you you're attempting to run an operation on something you cannot run operations on.
Performing calculations on NaN results in unpredictable behavior. There is absolutely nothing you can do with NaN mathematically that doesn't result in NaN, and there's no value for doing so. I think it's high time that we get a runtime error when attempting to perform math on NaN.
Nobody ever wants to run operations on NaN. It's always an accident or a bug in the code. If I try to set a Sprite's x to NaN, the runtime should throw an error that NaN is not a valid value for x, not draw the Sprite somewhere off screen. If I try to add, subtract, multiply, divide or any other mathematic operation on NaN, the runtime should throw an error that you cannot run mathematical operations on NaN.
Think about it this way. Being able to let the runtime do operations on NaN is AS1 style coding. It's not strict and the runtime doesn't let you know why something didn't work as expected. You have to go digging to figure it out. This is one of the biggest reasons to use AS3. Throwing runtime errors when running operations on NaN is AS3 style coding. It's strict and the runtime will let you know if you are trying to do something that will always be a bad result (such as trying to access a null).
Who's with me? Can I get some love for this suggestion?
Posted in AS3, Actionscript, Flash, Flex, Rants, Technology
June 12th, 2010 at 12:38 am
I find NaN very convenient in Flex framework when I want to force re- measurement cycle for my custom component, I set width or height to NaN and call invalidateSize().
I believe NaN is used extensively within Flex SDK, what will happen if Flash Player will start to throw RTE when NaN is encountered?
June 12th, 2010 at 1:52 am
I don't think it'll be such a good idea.
See, let's say you use parent.getChildByName("abc"), and it returns null.
Why is it alright for null not to throw an Error, but NaN to have an error?
Because like integer overflow, these 'errors' happen too often, and accidentally too, that throwing an error that cripples the user experience is too dangerous IMO.
June 12th, 2010 at 2:08 am
Oh. I just realised your comment was on returning an error on NaN operation haha….
Maybe they should merge NaN and null definitions internally in the Flash Player so they give the same error. Or maybe it's an ECMAScript thing haha..
June 12th, 2010 at 3:33 am
@JabbyPanda – what you're describing is a hack, at best. Setting width or height to a disallowed value in order to invalidateSize()? Why don't you just call invalidateSize() or your own forceMeasure() method?
If what you're saying is true, and the Flex SDK uses NaN in this manner a lot, then I am concerned. Taking advantage of a loophole in the player is not a good way to code components.
June 12th, 2010 at 4:11 am
I usually force the value to 0.0 to avoid calculation errors in this way:
value ||= 0.0;
June 12th, 2010 at 10:58 am
I don't think that it makes sense to throw errors if a NaN result ever occurs, but there should be an error if you try to perform an operation with a NaN input, for example if you try to add or multiply a NaN value. This is the case where NaN most often causes problems.
June 12th, 2010 at 11:03 am
That's what I'm suggesting. NaN itself isn't an error, but if you get an NaN and try to do something with it, then an error should be thrown.
June 16th, 2010 at 6:10 am
Not at all, NaN is very useful in some cases. It seems like the problem is in your own code and its lack of NaN handling.
Personally, I sometimes miss NaN in "int" and "uint" types, although I'm aware of why it's not there.
Anyway, let your code throw the error….
June 16th, 2010 at 5:26 pm
@philtre If you're not going to provide a single example of how NaN is "very useful" then your argument (and assumption that my code is the problem, when, in fact, DisplayObject doesn't have proper NaN handling and does unpredictable things when you set its x,y,width,height to NaN) has no merit.
June 21st, 2010 at 6:12 am
Not sure why many people disagree with your recommendation.
I too would prefer to have NaN always throw an error. When NaN bugs pop up in my code, they often take extra effort to track down as there is never an error thrown.
August 18th, 2010 at 11:21 am
If people is actually "using" NaN, it is like using the old hackish depthsystem – it is messy.
Testing every-single-number for NaN because you might have mistyped something elsewhere is just plain stupid. Let flash throw NaN errors.