KVO / Exception handling in Swift

Question

Please note that this question was written in july 2014, before swift 1.0 when I mostly ignored anything about swift and tried to "translate" code from objC to swift. This is not a good solution and I now know better. KVO is something we love in ObjC, but I strongly recommend not to use it in swift and explore some alternative in swift. http://blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html. Remember: if something is hard to do, then maybe it is not meant to be done.

As an obj-C dev, I've been used to KVO for, well, year, and one of the recurring problem is the potential unsafe of calling removeObserver:forKeyPath: I usually surround this with a @try...@catch clause... Now with swift, I haven't find yet the try ... catch thingy :) Any leads on how to workaround the problem?

Cheers

Here is a example of what i mean

override func viewDidLoad()
{
    super.viewDidLoad();

    self.summaryTextView.text = self.show?.overview;
    self.title = self.show?.title;
    if(self.show?.imageData)
    {
        self.posterImageView.image = UIImage(data: self.show?.imageData);
    }
    else
    {
        self.posterImageView.image = UIImage(named:"wait");
        show?.addObserver(self, forKeyPath: "imageData", options: NSKeyValueObservingOptions.New, context: nil);
    }

}


override func viewDidDisappear(animated: Bool)
{
     // Will crash if self was not a observer in the first place
     self.show?.removeObserver(self, forKeyPath:"imageData");
}

override func observeValueForKeyPath(keyPath: String!, ofObject object: AnyObject!, change: NSDictionary!, context: CMutableVoidPointer)
{
     self.posterImageView.image = UIImage(data: self.show?.imageData);

}

Note that [Swift 2](https://www.hackingwithswift.com/new-syntax-swift-2-error-handling-try-catch) now includes try/catch. — Robert Harvey, May 01 '16 at 20:04
Please also note that this question was written in july 2014, before swift 1.0 when I mostly ignore anything about swift and tried to "translate" code from objC to swift. This is not a good solution and I now know better. KVO is something we love in ObjC, but I strongly recommend not to use it in swift and explore some other way. http://blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html — Florian Burel, May 17 '16 at 10:10

score 1 · Accepted Answer · answered Jun 13 '14 at 00:16

1

As the other answer says, there's no try-catch in Swift yet. Honestly, I would discourage the use of try/catch in the scenario you mention. This can easily be solved by keeping track of your object's state, which is always a good thing in object oriented programming.

answered Jun 13 '14 at 00:16

xtravar

1,321
11
24

Wrong! It's never good to have state, even in OOP. http://stackoverflow.com/questions/1020653/how-can-you-do-anything-useful-without-mutable-state – Rodrigo Ruiz May 01 '16 at 07:50
I think that's a rather short-sighted comment that has nothing to do with this question. – xtravar May 01 '16 at 08:30
I think promoting state is overall bad for the programming community. Didn't mean to offend you, just don't wanna make our lives harder in the future when maintaining other people's code. – Rodrigo Ruiz May 01 '16 at 18:28
1

@RodrigoRuiz: It's seldom good to make absolute statements about anything. Insisting that all programs be stateless is patently ridiculous; the CPU that gave you the ability to write your comments here is *inherently stateful by design.* (the comment itself is state) – Robert Harvey May 01 '16 at 20:02
I think if you go around making comments that are irrelevant to the question, then you aren't helping anyone. An object has a state regardless of your feelings or declarations - relying on imprecise mechanics to determine code flow is bad practice. In fact, relying on blanket "on error do this" code is worse for maintenance. In this case, there is an implicit contract with the API - flagrantly violating it and ignoring errors is not good coding. – xtravar May 01 '16 at 20:05
@RobertHarvey I agree, "absolute statements" are usually wrong. That's why I think "keeping track of your object's state, which is ~always~ a good thing" is wrong, but that's just IMHO. – Rodrigo Ruiz May 02 '16 at 04:12
I agree that the API is bad, but relying on a try/catch would be more localized than keeping state in this case, therefore, I think it's better. I would have accepted your answer without saying anything if you said something like: "This API is really bad, therefore you can't even do try/catch (which would also be bad), the only hack you can do is keep track with a state variable." – Rodrigo Ruiz May 02 '16 at 04:13
@RodrigoRuiz Then you aren't following the API contract. Relying on try/catch is an anti-pattern. – xtravar May 02 '16 at 04:15
Again, that was just my opinion, I don't get why you're all so upset just because someone didn't agree with the main OOP stream of thought. And again, it's ok for you to think having a state there is better than try/catch (you are entitled to your opinion, just as I am to mine). What I think is bad is the thought of saying keeping state is definitely a good thing. You as a OO programer probably knows of the perils of tracking state. – Rodrigo Ruiz May 02 '16 at 04:20
Because saying "wrong!" and citing platitudes out of context actually does the opposite of what you want, which is to encourage maintainable code. – xtravar May 02 '16 at 04:35
The whole point is that there are perils to *not* tracking implicit state. This case is implicit based on the contract of the API. It may make sense to you to catch and ignore all errors, but explicit contracts are always more maintainable and preferred. Especially in this case, the API interaction does not always happen in the way you expect, and that is why there is the exception. – xtravar May 02 '16 at 04:46

KVO / Exception handling in Swift

1 Answers1