A common place I see nil swallowing is pulling arrays from a
dictionary or hash table.
NSArray * theArray = get_next(table);
int i, count = [theArray count];
for(i = 0;i < count;i++)
{
//do stuff
}
If the array is nil count is zero and the for loop is not entered.
Avoided adding another branch of execution by not needing to check for
nil.
Also when getting an NSData from somewhere, you can just check the
length > 0, this will be false if the data object is nil or the data
object has no data. Saves having to check both the pointer and the
length separately.
It's a double edged sword; it can save coding time and a lot of branch
evaluations if used properly and planned for but can also hide
problems where you didn't expect to get a nil.
On Apr 17, 2008, at 11:01 PM, Adam P Jenkins wrote:
don't understand how the nil-swallows-messages behavior relieves
you of having to check for errors. Maybe in throw-away code, but in
any production code I wouldn't want to just ignore errors and hope
the nil-swallows-messages behavior keeps the errors from being
serious.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
