1

I've read that sending messages to nil is allowed in ObjC and I understand that this is a part of the language and that there has been controversy about it, pro and con. I don't want to open up a discussion about any of that.

I just want to know if there is a way, short of always having to test if (presumedInstance != nil), that I can get errors when trying to send a message to nil? It is not helping me when coding that I don't get errors - makes it harder to determine where the code flaw is, etc.

Perhaps a setting or script in XCode?

spring
  • 18,009
  • 15
  • 80
  • 160
  • See answer to similar question: [Is there any way to log a message send to nil?](http://stackoverflow.com/questions/9883599/is-there-any-way-to-log-a-message-send-to-nil/9883619#9883619) – Kurt Revis Apr 15 '12 at 01:24
  • I think the main problem is that half of iOS would break if you changed the behavior, and there's no reasonable way to change the behavior for only your code. (I think there is theoretically a way to do it -- IIRC there's a standard method that gets called when a message is sent to nil and your app can (in theory) override that method.) – Hot Licks Apr 15 '12 at 02:34
  • (I agree that the "feature" hides errors and leads to sloppy coding practices. It has its advantages but on balance I'd rather do without it.) – Hot Licks Apr 15 '12 at 02:36
  • @HotLicks: No method, I'm afraid; it's just `objc_msgSend()` which does an early return for a `nil` receiver. – jscs Apr 15 '12 at 07:49

2 Answers2

2

No, there's no way to do this. In fact, it's a very important feature of Objective-C. I'd actually argue it's more important for you to do the testing (if (object), which is the same as if (object != nil)) because it forces you to consider the inputs and outputs of your functions and methods, and the code paths your application goes through. It might be frustrating at first, but it's one of the things you get used to, and it makes life much easier.

Itai Ferber
  • 28,308
  • 5
  • 77
  • 83
  • 1
    I disagree - it makes coding/debugging more tedious and brain dead c.f. we don't have to test if param type == expected param type because the compiler enforces type and/or exceptions will be thrown - but I appreciate you taking the time to offer your perspective. – spring Apr 15 '12 at 02:06
  • 1
    @skinnyTOD There are cases in which I agree with you. For the most part, it's almost never good to swallow errors without letting anyone know — it _does_ make debugging harder in a lot of cases, especially when people are just starting out. However, messaging `nil` isn't always a mistake, and it doesn't always hurt. I'm betting that a lot of times, the backtraces you'd get from exceptions being thrown because of messages to `nil` would be even less helpful and more confusing than not receiving errors. Think of all the headaches `NULL` brings to C (e.g. segfaults); `nil` is relatively harmless. – Itai Ferber Apr 15 '12 at 02:25
0

What about trying assertions, like with NSAssert?

NSAssert Generates an assertion if a given condition is false.

Usage : NSAssert(condition, desc)

Parameters :

  • condition : An expression that evaluates to YES or NO.
  • desc : An NSString object that contains an error message describing the failure condition.

Reference :

Community
  • 1
  • 1
Dr.Kameleon
  • 22,532
  • 20
  • 115
  • 223