[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: question regarding explicit exception in NSKeyValueCoding.m:429 -[NS
Re: question regarding explicit exception in NSKeyValueCoding.m:429 -[NSObject(KeyValueCoding) setValue:forUndefinedKey:]
Thu, 28 Jul 2011 15:25:52 +0100
On 28 Jul 2011, at 15:06, Sebastian Reitenbach wrote:
> the exception happens here:NSKeyValueCoding.m:429 -[NSObject(KeyValueCoding)
> This exception is unconditionally. I first tried to
> WANT_DEPRECATED_KVC_COMPAT, and recompiled, but that did not helped.
> Then I commented out the exception, and OGo is just fine with that.
> Obviously, libFoundation did not raised an exception, so I'm a bit wondering,
> who is/was right?
GNUstep is right. On OS X:
$ cat undefined.m
[[NSObject new] setValue: @"foo" forUndefinedKey: @"bar"];
$ clang -framework Cocoa undefined.m
2011-07-28 15:17:05.872 a.out[56109:903] *** Terminating app due to uncaught
exception 'NSUnknownKeyException', reason: '[<NSObject 0x100111410>
setValue:forUndefinedKey:]: this class is not key value coding-compliant for
the key bar.'
> I don't have a mac, so cannot check what would happen there if I'd run into
> this setValue:forUndefinedKey:?
It throws an NSUnknownKeyException. This is the documented behaviour when you
try to set a nonexistent key. Why is OGo trying to do this? What is it
expecting to happen?
> Anyways, instead of commenting out the exception, I guess I need to put an
> exception handler somewhere, and catch it?
> Am I on the right track here?
No, silently discarding missing key error is almost certainly the wrong thing
to do. If that is the desired behaviour for a specific class, then it should
override setValue:forUndefinedKey: and discard it, but more likely it should
not be setting values for keys that don't exist...