4 ms·
There are some annoying circumstances where you still have to check for nil, so it's not exactly consistent. For example: 1. Adding nil to an array triggers an
by rbritton 13y ago
There are some annoying circumstances where you still have to check for nil, so it's not exactly consistent. For example:
1. Adding nil to an array triggers an exception.
2. Trying to set a dictionary key/value pair with nil for either value triggers and exception. It'd be more consistent with other parts of the code base if setting a nil value unset that particular key.
3. Calling a block storage variable that's nil will crash.
It'd be nice if these all were no-ops too.
- jawngee 13y agoIt is consistent though. Sending a message to nothing gets your nothing. Adding nothing to something that expects something causes an exception.
- rbritton 13y agoI suppose it depends on what you consider consistent (i.e., all nil operations should be no-ops or just message-sending operations), but that only covers 1 and 2. Trying to invoke a nil block still crashes.
- paintstripper 13y agoThat's because blocks aren't completely objective-c objects. They can act like them in some cases, but underneath they are still C based. That's why you pass NULL instead of nil to specify an empty block.
- mikeash 13y agoAll of Objective-C is C based in the end. Blocks are completely Objective-C objects. Attempting to call a NULL block crashes not because blocks aren't Objective-C objects, but because block invocation is not a message send. Note that accessing an instance variable of a nil Objective-C object pointer will also crash, e.g.: obj->_ivar; That's obviously not because Objective-C objects aren't Objective-C objects. The crash when calling a nil block is the same thing.