[alextgordon]

I think when many people hear about ObjC's nil semantics, they use it as a pretext for dropping all their null checks. This is a mistake, and you're right, it will make debugging exceptionally difficult when nils start falling through five levels of functions and propagated through ivars.

The trick is to use null checks almost like you're writing C++, but drop them when they are unnecessary and inelegant. Convince yourself that a null check is unnecessary before removing it. This way you're reducing the chance of bugs and making them easier to pinpoint.

For example, you can do:

    if ([someArray count])

rather than

    if (someArray && [someArray count])

On the other hand, you may be asking for trouble if you do

    [[someArray lastObject] dance];

without checking [someArray lastObject] for nil, since if someArray is empty, then nothing will dance and you won't know about it.

tl;dr: Messaging nil is not idiot-proof but it makes code read better.

[ryanpetrich]

The worst offender is the comparison methods:

    NSString *myString = nil;
    if ([myString compare:@"something"] == NSOrderedSame) {
        ...
    }