Re: removeObserver:forKeyPath: when already removed
Re: removeObserver:forKeyPath: when already removed
- Subject: Re: removeObserver:forKeyPath: when already removed
- From: Jim Correia <email@hidden>
- Date: Wed, 11 Nov 2009 20:19:13 -0500
On Nov 11, 2009, at 7:36 PM, Jerry Krinock wrote:
>> Trying to remove an observer for a key path which has already been removed (or never registered) falls into the programming error class...
>
> Almost always true. But what if, and yes I know this is pretty flakey but just assume it could happen, that I needed to do some very expensive operation to determine whether or not an observation had been removed. Then, it would be efficient and smart to send the removeObserver:: message unconditionally.
I think that’s a bit of a stretch. It may be less tedious to always send -removeObserver:forKeyPath:, but it usually is not expensive (in either time or space) to keep track of the objects you are observing. (And since it is currently necessary, it is a mostly moot point.)
(For an extra bit of trivia, see the Snow Leopard release notes about automatic removal of observers on 10.6 and later when running under GC.)
> But how is the programmer to know this is an error if it's not documented as a "don't do"? If indeed this is not documented, then in my opinion it's a documentation error.
Without being overly pedantic, the documentation says:
observer
The object to remove as an observer.
keyPath
A key-path, relative to the receiver, for which observer is
registered to receive KVO change notifications. This value must not
be nil.
Combining the two, ‘oberver’ must be registered as an observer of ‘keyPath’ or else it is an error.
Could the documentation be more explicit? Sure.
Since this method has always raised an exception for this programming error, as soon as you commit this error you’ll get the exception and fix it.
The real problem for this type of exception comes when the exception is added for a programming error that used to be silently allowed (even if that error resulted in undefined behavior.) In this case, Apple cannot unconditionally add the exception, because they may break binary compatibility (such that it is) with applications relying on the silent, but undefined error behavior.
In these situations, an exception is usually added with a linked-on-or-after test, and documented in the release notes.
- Jim_______________________________________________
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