【问题标题】:KVO / Exception handling in SwiftSwift 中的 KVO / 异常处理
【发布时间】:2014-07-27 10:47:01
【问题描述】:

请注意,这个问题是在 2014 年 7 月写的,在 swift 之前 1.0,当时我几乎忽略了有关 swift 的任何内容,并试图将代码从 objC“翻译”为 swift。这不是一个好的解决方案,我现在知道了 更好的。 KVO 是我们在 ObjC 中喜欢的东西,但我强烈建议不要 在 swift 中使用它并在 swift 中探索一些替代方案。 http://blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html。 记住:如果某事很难做到,那么也许它不是注定要做到的 完成。

作为一名 obj-C 开发人员,我已经习惯了 KVO 一年了,而且经常出现的问题之一是调用 removeObserver:forKeyPath: 的潜在不安全性 我通常用@try...@catch 子句围绕它... 现在有了swift,我还没有找到try ... catch thingy :) 有关如何解决该问题的任何线索?

干杯

这是我的意思的一个例子

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);

}

【问题讨论】:

  • 请注意,Swift 2 现在包括 try/catch。
  • 感谢更新:)
  • 另请注意,这个问题写于 2014 年 7 月,在 swift 1.0 之前,当时我几乎忽略了关于 swift 的任何内容,并试图将代码从 objC“翻译”为 swift。这不是一个好的解决方案,我现在知道得更好了。 KVO 是我们在 ObjC 中喜欢的东西,但我强烈建议不要快速使用它并探索其他方式。 blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html

标签: ios swift


【解决方案1】:

正如另一个答案所说,Swift 中还没有 try-catch。老实说,我不鼓励在您提到的场景中使用 try/catch。这可以通过跟踪对象的状态轻松解决,这在面向对象编程中总是一件好事。

【讨论】:

  • 错了!即使在 OOP 中,拥有状态也不是一件好事。 stackoverflow.com/questions/1020653/…
  • 我认为这是一个相当短视的评论,与这个问题无关。
  • 我认为提升状态总体上对编程社区不利。没有冒犯你的意思,只是不想以后维护别人的代码时让我们的生活变得更加艰难。
  • @RodrigoRuiz:对任何事情做出绝对的陈述很少有好处。坚持所有程序都是无国籍的显然是荒谬的;使您能够在此处编写 cmets 的 CPU 在设计上天生就是有状态的。(注释本身就是状态)
  • 我认为,如果您到处制作与问题无关的 cmets,那么您对任何人都没有帮助。无论您的感受或声明如何,对象都有状态 - 依赖不精确的机制来确定代码流是不好的做法。事实上,依赖一揽子“错误时执行此操作”代码对维护来说更糟糕。在这种情况下,API 有一个隐含的契约——公然违反它并忽略错误并不是好的编码。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-04-03
  • 2016-04-25
  • 2016-01-21
  • 2020-06-26
  • 2017-05-10
  • 2016-12-08
  • 1970-01-01
相关资源
最近更新 更多