and you’ll get back NO as the answer. So far, so sensible.
Now do this:
Congratulations! You just earnt yourself an exception.
This inconsistency between classes seems rather weird. Why don’t they behave the same? I’d argue that nil should be accepted by both, so that phrasing the test the other way round performs the same:
Both of the above cheerfully return you NO, since that’s what sending a (BOOL-returning) message to nil always gives. Wouldn’t it be nice if all four of these examples worked the same way?
Sadly, I think the chances of Apple changing Foundation’s behaviour after all this time are rather slim — let alone the headaches of remembering not to use it when targeting existing OSs. Particularly when I combed the docs and found this nugget:
In all isEqualToType: methods of the Cocoa frameworks, nil is not a valid parameter and implementations of these methods may raise an exception upon receiving a nil. However, for backward compatibility, isEqual: methods of the Cocoa frameworks do accept nil, returning NO.
So it seems that NSString is the one at fault here. Time to start replacing your calls to ‑isEqualToString: with ‑isEqual: instead? Well, probably not worth it, as, again, Apple are unlikely to pull the rug out from under you on this. But if you decide to, it fortunately seems that ‑isEqual: is basically as fast anyway.