What does "sending a message to nil" mean, and why is it a special case?
Solution 1
The special treatment of nil
means that you can do the following:
SomeClass * someObject;
someObject = nil;
[someObject doSomething];
And you can be assured that nothing will happen.
Now, why is this important?
In Objective-C, sending a message to an object means telling that object to do something, or asking that object for some information. Some examples:
[someObject updateRecords]; // 1
x = [someObject size]; // 2
Line 1 sends someObject
a message called updateRecords
, and line 2 sends the same object a message called size
, which is expected to return a value. These messages boil down to method calls, and the actual code that ends up being run is determined by the Objective-C runtime system, since Objective-C is a dynamically-typed language.
To determine which method to invoke, the runtime system reads information from the address of the object in question (someObject
, in the examples above) to work out what class it is an instance of. Using that information, it is able to look up the appropriate method to call, and when all that has been figured out, it executes the code in the method.
If the runtime system did not treat nil
as a special case, it would probably crash if you tried to execute the code shown at the top. nil
is defined to be zero, so the runtime would start reading information from an address stored at location zero in memory, which is almost gauranteed to be an access violation.
Solution 2
- nil is basically a null pointer (i.e. it is the number zero stored in a pointer).
- All messages to nil are legal (they won't cause a crash), but they don't do anything.
- All messages to nil return nil, or 0, or 0.0, or NO, depending on the return type.
Solution 3
You can send any message to nil. Nothing happens.
What exactly is it you don't understand in those docs?
Solution 4
The great thing about nil messaging compared to other languages like C# is that you can write code that performs multiple method calls without having to test for nil at each step.
id obj1 = [SomeClass object];
id obj2 = [obj1 doSomething];
id obj3 = [obj2 anotherMethod];
id thingICareAbout = [obj3 doSomethingElse];
If you go through several steps to get to thingICareAbout
, it saves a lot of unnecessary lines of code to not have to test if obj1, obj2 and so on are nil before using them. You can just check if thingICareAbout
is nil once at the end if you need to. Sometimes you don't even have to do that, if your code still works when it's nil (or 0 for primitive values).
In C# you would have had to explicitly check if each object is nil, set up exception handling around that block of code, or just hope none of the intermediate objects are ever nil.
One other thing to keep in mind (that I just learned myself!) is that 10.5 changed this behavior-- it used to be that it was only safe for integers and pointers to objects, not structs or floating point values. You might see some additional error checking when you're looking at other code because of this.
Solution 5
It does what you would expect: nothing.
Comments
-
Blankman almost 2 years
I just started reading the Objective-C tutorials, and there is a section on "sending a message to
nil
":There are several patterns in Cocoa that take advantage of this fact. The value returned from a message to nil may also be valid:
What does this mean? I can't seem to follow it.
-
Blankman over 14 yearswhat is nil? Are you seding the value null to a object's method? or sending the value null to a message? what messagE?
-
mipadi over 14 years"nil" is a null object. If you're familiar with Java, "sending a message to nil" is equivalent to "calling a method on null" in Java, except that in Java, you get a NullPointerException, whereas in Objective-C, nothing happens. So you can safely do something like "[nil doThis:withThis]" and the program won't crash (the method will just return nil).
-
Werner over 14 yearsNot exactly. Nil is equal to 0, it's not an object. This is why you can do the same thing with methods that return an integer value. There is a special NSNull object that you can use in collections classes, but it is not equal to nil.
-
Chuck over 14 years@Marc: All objects evaluate equal to some integer. You can send messages to nil (something that is true of every object and not true of nonobjects in Objective-C), so conceptually at least, nil can meaningfully be called an object. It is a special value, though.
-
TOMKA over 14 yearsPoint 3 depends on the runtime. In older runtimes the documentation said you couldn't rely on the return value of messaging nil if the method returned floats, doubles or greater-than-natural-word-sized variables.
-
TOMKA over 14 years"nil" usually refers to a nil instance and "Nil" usually refers to nil class. I think in the GNU runtime they are actually explicitly cast (id)0 and (Class)0, but I currently only have access to the NS runtimes. Pre 10.5 runtimes defined nil and Nil to just 0, but 10.5 defines them to __DARWIN_NULL.
-
bacar about 12 yearsVery few people that are familiar with popular languages such as Java, C# or C++ would expect this to do nothing. They'd expect an exception or a crash.
-
onmyway133 over 10 yearsSo why in raywenderlich.com/2696/…, they say "sending a message to deallocated memory causes a crash" ?
-
Mathias over 10 yearsSending a message to deallocated memory (also known as a zombie) can happen if you release an object but still retain a pointer to the old memory location. For example:
[someObject release]; [someObject someMethod];
. This is very different fromsomeObject = nil; [someObject someMethod];
Even though setting someObject to nil may release it in a GC environment, the act of setting it to nil will also prevent you from sending a message to the deallocated memory.