Nil check before add child?

clam61

Is there a reason that the framework does not check for a nil object in addChild:atIndex: before adding to the array?

Is there a way I could request this fix be made in future versions (I have already amended my version) of this wonderful framework?

iosNighthawk

Not sure if anyone feels the same, but my thought would be performance reasons.

If I was calling addChild:atIndex on some enter_frame or loop it would actually bother me if Sparrow had the extra conditional there. That's something I would leave to the developer.

It actually bothers me a little that SPViewController:glkView:drawInRect() has the conditional for checking if root exists. I might end up commenting that out which is the great thing about Sparrow being exposed. But, I'm also a nut when it comes to gaining every ounce of performance. Having to develop web games will do that to you.

Daniel

Clam61, what would be the value of such a check? When you pass "nil" to the method, it crashes anyway, right?

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: -[__NSArrayM insertObject:atIndex:]: object cannot be nil'

So the check is done by the NSArray method already; all that I could do is throw another error. (Or do you mean I should ignore the nil value?)

iosNighthawk, indeed, I hated to have to add that check there, as well. It was the only way to assure that the root object is created only after I know the width and height of the view controller. (If you ask me, a bug in the SDK.) 😐

However, in reality, it's not a performance problem at all. It's only one if-statement per frame, after all.

clam61

what i meant was, if the argument to addChild is nil, do not try to add it to the display list

basically to avoid having to write the if selection every time:

if (child != nil) {
    [self addChild:child];
}

Shilo

I believe it is sometimes necessary to raise an error whenever an object is nil, this way there is no chance of unexpected behaviors. Also, as stated above, adding an extra if statement may lower overall performance, even if it's unnoticeable. Personally, I would prefer it without the if statement.

If you prefer an if statement, you can always modify the source yourself, or create a category that overrides the addChild:atIndex: method (which, btw, will create a linkage warning, although I have never have a real problem associated with those warnings). Or you can create new methods via the category, such as "addChild2:" or "addValidChild:" which simply check if the object is nil.

Daniel

I agree with Shilo!

It's an edge-case, really. Sometimes, it's better to throw an exception if you get a nil object; in other cases, it's better to just do nothing. In this case, I'd opt for the former.