Hacker News Reader

Comment by program | Hacker News Reader

In my opinion the confusing part is not about SEGFAULT or NullPointerException. Let's make and example:

   NSArray *obj = nil;
   [obj count]; // return 0

In theory a nil object can hide in your code for a long time if you only use methods that can return 0.

View on HN

It's a trade-off, because it's convenient to not have to check that objects are non-nil when you send messages to them. With experience, you learn to deal with code that requires non-nil objects via assertions:

    NSAssert(array, @"Array can't be nil.");

There is no "natural" behavior to a beginner. Either way has to be learned and understood. Nil messaging behavior is only going to be confusing to people who learned one way and internalized it enough to think of it as "the way", then were exposed to the other way. Java programmers going to ObjC will find ObjC's nil handling confusing, and ObjC programmers going to Java will find Java's null handling confusing.

Reply on news.ycombinator.com