what does sending a message to nil mean, and why is it a special case?

Question

I just started reading the Objective-c tutorials, and there is a section on sending a message to nil.

What does this mean? I can't seem to follow it.

Answer 1

You can send any message to nil. Nothing happens.

What exactly is it you don't understand in those docs?

Answer 2

It does what you would expect: nothing.

Answer 3

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.

Answer 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.

Answer 5

• 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.