swift – 强制施法真的很糟糕,应该总是避免吗?

前端之家收集整理的这篇文章主要介绍了swift – 强制施法真的很糟糕,应该总是避免吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我开始使用 swiftLint,并注意到 Swift最好的做法之一是避免强行施放.但是我在处理tableView时使用了很多,对于单元格来说是collectionView:
let cell = collectionView.dequeueReusableCellWithReuseIdentifier(cellID,forIndexPath: indexPath) as! MyOffersViewCell

如果这不是最好的做法,那么正确的处理方法是什么?我想我可以使用,如果让我们,但这是否意味着其他条件我将需要返回一个空单元格?这可以接受吗

if let cell = collectionView.dequeueReusableCellWithReuseIdentifier(cellID,forIndexPath: indexPath) as? MyOffersViewCell {
      // code
} else {
      // code
}
这个问题大概是以意见为基础的,所以我用一粒盐来答复我,但是我不会说强制下降总是坏的;您只需要考虑语义,以及在特定情况下如何应用.

如! SomeClass是一个合同,它基本上说“我保证这个东西是SomeClass的一个实例”.如果事实证明它不是SomeClass,那么将会抛出异常,因为你违反了合同.

您需要考虑使用此合约的上下文以及如果您没有使用强制下放,您可以采取何种适当措施.

在您给出的示例中,如果dequeueReusableCellWithIdentifier不给您一个MyOffersViewCell,那么您可能错误地配置了与单元重用标识符有关的一些功能,并且异常会帮助您找到该问题.

如果你使用了一个有条件的downcast,那么你将要消失,不得不处理 – 记录一个消息?抛出异常?它确实代表了一个不可恢复的错误,并且您希望在开发过程中找到它;你不会期望在发布后不得不处理.你的代码不会突然开始返回不同类型的单元格.如果你只是让代码崩溃的力量downcast它将直接指向出现问题的行.

现在,考虑一个您正在访问从Web服务检索的JSON的情况. Web服务可能会发生变化,这是您无法控制的,因此更优雅的处理可能会很好.您的应用可能无法运行,但至少您可以显示警报,而不是简单地崩溃:

BAD – 如果JSON不是数组,则会崩溃

let someArray=myJSON as! NSArray 
 ...

更好 – 处理带有警报的无效JSON

guard let someArray=myJSON as? NSArray else {
    // Display a UIAlertController telling the user to check for an updated app..
    return
}

猜你在找的Swift相关文章