3 ms·

If you're smart enough to test for it returning 0, you're smart enough to test if it is 0. And if you're stupid enough.. now it fails silently?

• BigZaphod 17y ago
  In Objective-C you often end up with patterns like this: if ([[obj delegate] shouldThisDoSomething]) { ... stuff ... } When calling "delegate" on obj, it might return nil if there isn't one set (or if obj itself is nil). If it does return nil, sending "shouldThisDoSomething" results in 0 (aka nil). nil == false, So "stuff" will never happen - which is pretty much as expected in 99%* of cases. (* made up statistic) This behavior, combined with a few rules like naming certain methods in a way that asks permission rather than forbids an action, gets you an entire system where you can almost completely forget about the issue while retaining programmer control for the few special cases where it might matter and you can test for it. (Nil also sticks out like a sore thumb in the debugger if you're stepping through and trying to figure out why something didn't work like you thought it should.) Aside: Nothing fails silently unless you never test it. It's just a matter of how you're exposed to the failure. IMO, sending to nil resulting in 0/nil is very good at eliminating a lot of if/else boilerplate for certain situations which means less code cluttering my screen.