Re: The joys of people using valueForKey to get objects out of a dictionary.
Re: The joys of people using valueForKey to get objects out of a dictionary.
- Subject: Re: The joys of people using valueForKey to get objects out of a dictionary.
- From: Alex Zavatone <email@hidden>
- Date: Tue, 10 Nov 2015 15:21:16 -0500
- X_v_e_cd: 89b0c2fb84bf6eaa9cf41f2540646145
- X_v_r_cd: ed09c38783cc68d33bea780748a73237
On Nov 10, 2015, at 2:15 PM, Jens Alfke wrote:
>
>> On Nov 10, 2015, at 10:52 AM, Alex Zavatone <email@hidden> wrote:
>>
>> Here's a great reason to use objectForKey: wherever possible instead of valueForKey: - valueForKey: with an unknown key will throw NSUnknownKeyException saying "this class is not key value coding-compliant for the key ".
>
> Yes, but that’s a non-issue with NSDictionary because there are no unknown keys. It handle any key (that doesn’t start with an @) by looking it up in the dictionary.
>
> I’m not saying you should use -valueForKey, just that you need to be clear on its behavior on _arbitrary_ objects vs. its behavior with NSDictionary.
>
>> But if we remove the @ (obviously unintended), valueForKey causes an EXC_BAD_ACCES while objectForKey reports "error: string literal must be prefixed by '@'".
>
> Um … you’re doing that in lldb? The difference there seems like an lldb bug. It shouldn’t be allowing you to pass a C string literal as an id, no matter what method is being called.
Yeah. Honestly, I'm looking for cases that would justify why all the dictionary object access blocks in this code that use valueForKey are wrapped with @try/@catch clauses. I've never seen cases with objectForKey that would trying to catch exceptions accessing dictionary objects.
>> And David does state that whether an exception is thrown or not is implementation dependent.
>
> Yes, the implementation OF THE CLASS BEING CALLED. Which is NSDictionary. Which, as we keep saying, handles any key by looking it up in the dictionary.
In any case, I don't wish to waste anyone else's time on this (unless you find it interesting).
Thanks again for all the background info on this.
Cheers.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden