6

I have some code that uses KVO heavily and have addObserver:forKeyPath: and removeObserver:forKeyPath: in multiple places. The app will occasionally crash with "cannot remove observer for key path."

I was wondering if it would be safe to just try/catch the exception to prevent the app from crashing. I know it's not the best approach in handling KVO but I need to buy some time before I can clean up the code.

Tendulkar
  • 5,550
  • 2
  • 27
  • 53
Jiho Kang
  • 2,482
  • 1
  • 28
  • 38
  • 2
    You should probably try to understand the nature of failures first and decide whether you can ignore it. Try / catch will help if you decide so : http://stackoverflow.com/questions/1582383/how-can-i-tell-if-an-object-has-a-key-value-observer-attached – Tala Aug 16 '13 at 09:31

2 Answers2

5

Exceptions, especially from internal Apple APIs, should never be silently caught and ignored. In Objective-C an exception should generally cause your app to terminate, unlike other languages and runtimes (Java, .NET) where catching exceptions is a normal part of development.

If you are getting a crash, you have a bug somewhere and you need to fix it. Swallowing an exception could have pretty bad consequences due to getting into an inconsistent state. Don't do it.

Mike Weller
  • 45,401
  • 15
  • 131
  • 151
  • 1
    So your recommendation is to clean up the code even if it does require that extra amount of time and delaying a release? Like I mentioned I do understand that I need to fix my code. Just trying to work out the economics at this point. Thanks – Jiho Kang Aug 16 '13 at 10:59
  • 1
    @JihoKang So you want to ship an app which has an obvious bug? Do you even know what the effects will be? Right now the app is crashing; What do you think your app is going to do when you swallow the exception? – Abizern Aug 16 '13 at 11:02
  • @Abizern The project I'm working on is rather time critical and the crash bug (as far as I've seen with beta testers) only occurs under 5% of the time. I've written the code so that there are cases due to timing issues in which an object that has already unregistered from KVO will try to unregister again. I've tested catching the "cannot remove observer for key path." exception without side effects "as far as I can see" but was just wondering exactly how critical of an issue it might be. After all as Mike mentioned this is common practice in Java. – Jiho Kang Aug 16 '13 at 11:27
  • @JihoKang You aren't writing Java. Still - your choice. – Abizern Aug 16 '13 at 11:29
  • 2
    @Abizern Sorry, I have to disagree with this, and agree with [NSHipster (Mattt Thompson)'s post](http://nshipster.com/key-value-observing/) – Mazyod Apr 15 '14 at 08:53
5

Yes, it can be perfectly acceptable to utilize @try @catch to resolve these sorts of KVO conflicts.

For example:

@try {
        [[NSNotificationCenter defaultCenter] removeObserver:self forKeyPath:UIDeviceProximityStateDidChangeNotification];
    }
@catch (NSException *exception) {
        // observer doesn't exist, do nothing
    }

is production safe and is suggested by Apple as an appropriate exception handling pattern.

Yup.
  • 1,883
  • 21
  • 18
  • Old topic, but deprecated official documentation link is https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOBasics.html#//apple_ref/doc/uid/20002252-178612 – kikeenrique Feb 25 '19 at 22:00