views:

282

answers:

4

I tried something along the lines of:

if(myString != nil && myString.length) { ... }

And got:

-[NSNull length]: unrecognized selector sent to instance

Does Objective-C not short-circuit after the first condition fails?

+6  A: 

Objective-C is a strict superset of C.

Because C supports short-circuit evaluation, Objective-C does as well.

Stephen Canon
+3  A: 

What is NSNull defined as? If it is an object that is supposed to represent nothing, than it would not be nil. in other words, NSNull and nil aren't the same.

darren
+11  A: 

Objective-C does support short-circuit evaluation, just like C.

It seems that in your example myString is NSNull and not nil, therefore myString != nil is true.

NSNull is a singleton and is used to represent nil where only objects are allowed, for example in an NSArray.

Btw, normally, people write if (!myString && myString.length == 0). Comparing to nil is quite ugly. Also, I'd compare the length to 0. That seems to be more clear.

Georg
ifwdev
I wouldn't say people 'normally' don't compare to nil. I've seen it done both ways with equal frequency. The argument being that you can read it as 'if myString is not nil' as opposed to 'if not myString'.
bobDevil
A: 

If you have an NSNull somewhere, you are probably either using a JSON parser or CoreData. When a number in CoreData is not set, CodeData will give you back NSNull - possibly the same goes for NSString values in CoreData too.

Similarly, you can have empty elements in JSON returned from a server and some parsers will give you that as an NSNull object. So in both cases, you have to be careful when you are using values since the thing you thought was an NSString or NSNumber object is really NSNull.

One solution is to define a category on NSNull that simply ignores all non-understoon messages sent to the object, as per the code below. Then the code you have would work because NSNull.length would return 0. You can include something like this in your project .pch file, which gets included in every single file in your project.

// NSNull+IgnoreMessages.h
@interface NSNull(IgnoreMessages) 
- (void)forwardInvocation:(NSInvocation *)anInvocation;
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector;
@end

//NSNull+IgnoreMessages.m
#import "NSNull+IgnoreMessages.h"
@implementation NSNull(IgnoreMessages)
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
    if ( [self respondsToSelector:[anInvocation selector]] )
      [anInvocation invokeWithTarget:self];
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
{
    NSMethodSignature *sig=[[NSNull class] instanceMethodSignatureForSelector:aSelector];
        // Just return some meaningless signature
    if(sig==nil)
      sig=[NSMethodSignature signatureWithObjCTypes:"@^v^c"];

    return sig;
}
@end
Kendall Helmstetter Gelner
That's just waiting to fail. It's important to know when you're dealing with `NSNull` instead of `nil`, your code makes that less likely to happen. In the question's example there's an error message containing `NSNull`, you wouldn't see that with your code and `if (myString)` would still evaluate to true.
Georg
So tell me how can it fail if you can send any message to it, just like nil... and it will still call through to any message actually understood by NSNull (including all NSObject methods).Now it can cause bugs, in that if you check expressly for equivalence to nil that will not be true. But in most coding, exactly because nil can be sent any message I just test against something like ( myString.length > 0 ) which works fine here. Indeed, this code will PREVENT possible crashes in your code when an NSNull slips in where you did not expect it, so on the balance it is a stability gain.
Kendall Helmstetter Gelner
Also, where does it say is an error message? That doesn't even make any sense, why would anything wanting to send back an error message ever send NSNull in place of a NSString? In practice I have only ever seen NSNull coming out of CoreData and some JSON Parsers, in ways where this test does nothing except prevent non-obvious runtime errors. You can still check for NSNull where important.
Kendall Helmstetter Gelner
The error message is mentioned in the question: *-[NSNull length]: unrecognized selector sent to instance*. I think it's extremely dangerous to say that your technique prevents crashes. Those crashes would only exist because the programmer _didn't see that NSNull gets returned._ This is a perfect example of masking bugs. And in this case, it could lead to data loss if there is some logic doing something with `NSNull`.
Georg