0

I'm new with Objective C and am not an uber programmer anyway but one thing I find odd is that it won't throw errors sometimes when objects are declared not initialized.

I just ran into this again - I had some setup stuff to be done in so I put it in an init function - but the class is a UIViewController that is wired up in the storyboard. So init was never called - and that's my error - (lots of NSObject derived classes in the project and I rushing and just tossed that in to test some things).

But my methods that were making calls to the instance that was supposed to have been set up in int didn't throw errors - it just that the values I was expecting were nil.

Isn't that sort of odd that that sort of stuff would fail silently?

spring
  • 18,009
  • 15
  • 80
  • 160

3 Answers3

5

You've got two separate issues here, both quite common for beginners.

  1. Your init was never called because it's the wrong method entirely. It's not the designated initializer for a view controller, and in any case a view controller from a nib or storyboard gets initWithCoder:. So it's up to you to have a sense of what method will be called and when.

  2. Messages to nil return nil with no error. This is a deeply entrenched feature of Objective-C and isn't going to change. There is often quasi-religious debate about it, and there are some clever ways around it, but that's neither here nor there really. Basically it's up to you to use lots of NSLog and lots of nil-checking (NSAssert is a great thing to use for this), especially during early stages.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Self-advertisement warning: My new book http://shop.oreilly.com/product/0636920023562.do would have warned you about both these things. It's full of cautions about gotchas that happen to real learners, drawn from my own experience. – matt Mar 17 '12 at 20:27
  • I know I made the error calling `init` - and I understand the nature of the mistake I made (aside from being sloppy). I guess since the compiler barks so much about various errors, I wasn't expecting that the language would give me a pass on something which would, in most of the circumstances I can think of, be a critical error. – spring Mar 17 '12 at 20:40
  • Well, now you know. "Why does Objective-C allow messages to nil" is a top FAQ so you're better off doing a Google search. Here's a pretty good discussion that hits most of the high points: http://stackoverflow.com/questions/156395/sending-a-message-to-nil – matt Mar 18 '12 at 18:15
1

Not odd at all. That's how Objective-C has always worked. Messages to nil simply do nothing.

Kurt Revis
  • 27,695
  • 5
  • 68
  • 74
  • thanks. I recall reading about sending msgs to `nil` and didn't really appreciate a real world case where one would *want* to do that. Wouldn't if be better for catching coding errors if an exception were thrown? I guess that the answer to that is no - but I don't understand why. – spring Mar 17 '12 at 20:30
0

It is strange, but that's how Obj-C was designed. Actually, from Obj-C perspective, the code did not fail (silently). Everything was correct.

In Obj-C you can alwyas send messages to ("call methods on") nil.

init is just another message ("method"), not a constructor. It's not needed to create and use an object. You can understand Obj-C only as a thin layer over C language. C language won't report if you haven't called a function on a struct, either.

Sulthan
  • 128,090
  • 22
  • 218
  • 270