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

13,012

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.

Share:
13,012
Blankman
Author by

Blankman

... .. . blank

Updated on June 19, 2022

Comments

  • Blankman
    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
    Blankman over 14 years
    what is nil? Are you seding the value null to a object's method? or sending the value null to a message? what messagE?
  • mipadi
    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
    Werner over 14 years
    Not 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
    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
    TOMKA over 14 years
    Point 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
    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
    bacar about 12 years
    Very 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
    onmyway133 over 10 years
    So why in raywenderlich.com/2696/…, they say "sending a message to deallocated memory causes a crash" ?
  • Mathias
    Mathias over 10 years
    Sending 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 from someObject = 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.