2

for example:

NSString *myString = [[NSString alloc] init];
if (nil == myString) {
    return;
}

Need I do this??Thank you!

DJean
  • 334
  • 3
  • 15
  • I think [nil message] is ok, so you just need to check for more specific problem when not objects are involved and when a train of such silent fails can lead to a problem that needs to be explicitly managed – ShinTakezou Jul 03 '11 at 11:12

3 Answers3

4

No, you don't need to do that, and I can't say I've ever seen code that made pervasive use of that pattern.

Also, the if statement can be shortened to: 

if (! myString) {
    return;
}

...which is equivalent though no less superfluous. Checking for nil can be useful, but is typically not done immediately after object instantiation. Instead the typical case is to do it to ensure that an object is not over-released, for instance using a pattern like:

if (myObj) {
    [myObj release];
    myObj = nil;
}

Note that calling any method on nil is allowed in Objective-C, so less harm is caused by an unexpected nil value floating around than in languages like Java where attempting to do anything with a null reference throws an exception.

aroth
  • 54,026
  • 20
  • 135
  • 176
  • Your second snippet does not make sense. If `myObj` is `nil`, then calling `release` on it will have no effect. There's absolutely no reason to check for `nil` in that case -- it doesn't "ensure that an object is not over-released". – jscs Jul 03 '11 at 18:08
  • @Josh Caswell - You're fixated on the `if`. The part that ensures `myObj` is not over-released is the `myObj = nil` line following `[myObj release]`. The `if` serves no purpose beyond readability and preventing a pointless call to `[nil release]` and a pointless assignment of `nil = nil`. – aroth Jul 03 '11 at 21:56
  • Not sure why I'm "fixated" since the `if` is what the question was about, and what your answer said: «Checking for `nil` can be useful...the typical case is to do it...», but okay. – jscs Jul 04 '11 at 03:03
1

Objective-C allows to call on nil pointers, that differs the language from many others and allows to skip some checks. Of course, it's still wise to check for == nil in some particular cases, however, you don't have to check every step in the code. Take a look at Apple's documentation and samples and try to follow their style.

Gobra
  • 4,263
  • 2
  • 15
  • 20
1

Frankly, most iPhone app code produced these days assumes that an out-of-heap condition (the only logical reason for such a simple instantiation operation to fail) never occurs in normal operation. Only when creating large (eg, image) objects might one check for allocation failure.

Of course, init routines can fail for a host of reasons, so checking for nil following a complex instantiation operation may be warranted (depending on the object type). (And remember that many other methods of some objects can return nil under some circumstances as well, so you need to read the specs and code accordingly.)

Hot Licks
  • 47,103
  • 17
  • 93
  • 151