> In other languages, like C++, this would crash your program, but in Objective-C, invoking a method on nil returns a zero value. This greatly simplifies expressions, as it obviates the need to check for nil before doing anything:<p><pre><code> // For example, this expression...
if (name != nil && [name isEqualToString:@"Steve"]) { ... }
// ...can be simplified to:
if ([name isEqualToString:@"steve"]) { ... }
</code></pre>
Wow, that is some bad, bad code. Consider this snippet instead:<p><pre><code> if ([name isDifferentFromString:@"bob"]) { ... }</code></pre>
Also for what its worth, variable declarations are not nil by default, this bug tied me up for quite some time.<p><pre><code> NSString *val;
if(something){
val = @"hello";
}else if(somthingelse){
val = @"goodbye";
}
if(val){
[self display:val];
}
</code></pre>
this can send you on a wild goose chase for not declaring val = nil initially.
It's worth noting that Go has interesting handling for empty values as well. A nil basically means "the zero value for a given data type". Thus, an empty array compares equal to nil: <a href="http://tour.golang.org/#36" rel="nofollow">http://tour.golang.org/#36</a>
Good article overall. However, I must object to this bit:<p>"C represents nothing as 0 for primitive value"<p>That's not true. There <i>is</i> no "nothing" for integer types, and floats either also lack "nothing", or have NaN as their "nothing", depending on your perspective.<p>One of the (many) annoying features of C-style NULL is that it means that some types are effectively option types while other types aren't, and there's no decent way to make them so. An NSString* is inherently "pointer to NSString or nothing", but an int is always an int, and I have to either carve out a special value to mean "nothing" (e.g. -1 used as the error return from a lot of UNIX syscalls) or use a separate flag.
Nice article, but I just wanted to throw out that if being able to call a class method on a null object in C++ is desirable, you can actually check for that condition instead of just crashing.<p><pre><code> if(!this) return false; // Or whatever
</code></pre>
Of course it's open for debate as to whether this is something to encourage, but it can help from having to use a Null Object pattern in some situations.
Just a reminder for C and C++ programmers: NULL considered harmful. Instead, use a literal 0 or (void * ) 0 in portable code.<p>In the C Standard, an implementation can define NULL as either 0 or (void * ) 0. For an example of how that can go terribly wrong, consider the following:<p><pre><code> printf ("%p\n", NULL)</code></pre>
on an architecture where sizeof (int) != sizeof (ptr)
Java is not identical to Obj-C but the 'null' fiasco is mindboggling...<p>Back when the book *"Effective Java" came out, a truly great advice was to use empty arrays everywhere you could instead of null.<p>The second enlightenment came to me when the smart brains at JetBrains decided to ship IntelliJ IDEA with the @NotNull annotation. I basically started to annotate as many methods returning something as @NotNull and then saw the number of NullPointerException go drastically down.<p>It's not possible everywhere but once you start to think about it, you realize that you don't need nearly as many null references as you think you did.<p>Then you started having IntelliJ IDEA warning you real-time (even on incomplete source file) about "reference xxx is never going to be null" (so the non-null check is pointless) or "warning: reference to xxx may be null". Great stuff. Years later there are still 99% of all the Java codebase not using the @NotNull annotation. Sad but true.<p>Now of course other language's take on the subject are interesting too: the maybe monad, the way Clojure deals with empty / nil sequences, etc.