武力真的很糟糕，应该始终避免吗？ [英] Is force cast really bad and should always avoid it?

问题描述

我开始使用swiftLint，并注意到Swift的最佳实践之一是避免强制施放。但是在处理tableView，cell的collectionView时我经常使用它：

I started to use swiftLint and noticed one of the best practices for Swift is to avoid force cast. However I used it a lot when handling tableView, collectionView for cells :

let cell = collectionView.dequeueReusableCellWithReuseIdentifier(cellID, forIndexPath: indexPath) as! MyOffersViewCell

如果这不是最佳做法，那么正确的处理方法是什么？我猜我可以使用if with as ?，但这是否意味着在其他情况下我需要返回一个空单元格？

If this is not the best practice, what's the right way to handle this? I guess I can use if let with as?, but does that mean for else condition I will need to return an empty cell? Is that acceptable?

if let cell = collectionView.dequeueReusableCellWithReuseIdentifier(cellID, forIndexPath: indexPath) as? MyOffersViewCell {
      // code
} else {
      // code
}

推荐答案

这个问题可能是基于观点的，所以我的回答有些含糊，但我不会说强迫降落总是 不好；您只需考虑语义以及在给定情况下的语义。

This question is probably opinion based, so take my answer with a grain of salt, but I wouldn't say that force downcast is always bad; you just need to consider the semantics and how that applies in a given situation.

SomeClass 是一个合同，它基本上说我保证这件事是SomeClass的实例。如果事实证明它不是SomeClass，则将因您违反合同而引发异常。

as! SomeClass is a contract, it basically says "I guarantee that this thing is an instance of SomeClass". If it turns out that it isn't SomeClass then an exception will be thrown because you violated the contract.

您需要考虑使用此合同的环境以及如果不使用强制降价措施可以采取什么适当的措施。

You need to consider the context in which you are using this contract and what appropriate action you could take if you didn't use the force downcast.

在您给出的示例中，如果 dequeueReusableCellWithIdentifier 没有给您 MyOffersViewCell ，则可能是因为与单元重用标识符有关的配置错误，并且异常会帮助您发现该问题。

In the example you give, if dequeueReusableCellWithIdentifier doesn't give you a MyOffersViewCell then you have probably misconfigured something to do with the cell reuse identifier and an exception will help you find that issue.

如果您使用了条件下调，那么您将得到nil并且必须以某种方式处理该问题-记录一条消息？抛出异常？它肯定代表着不可恢复的错误，是您在开发过程中想要发现的错误。您不必期望在发布后就可以处理。您的代码不会突然开始返回不同类型的单元格。如果只是让代码在强制向下转换时崩溃，它将直接指向发生问题的行。

If you used a conditional downcast then you are going to get nil and have to handle that somehow - Log a message? Throw an exception? It certainly represents an unrecoverable error and something that you want to find during development; you wouldn't expect to have to handle this after release. Your code isn't going to suddenly start returning different types of cells. If you just let the code crash on the force downcast it will point straight to the line where the issue occurred.

现在，考虑一种情况，您正在访问检索到的JSON来自网络服务。 Web服务中可能存在无法控制的更改，因此，更优雅地处理此问题可能会很好。您的应用可能无法运行，但至少您可以显示警报而不是简单地崩溃：

Now, consider a case where you are accessing some JSON retrieved from a web service. There could be a change in the web service that is beyond your control so handling this more gracefully might be nice. Your app may not be able to function but at least you can show an alert rather than simply crashing:

错误-如果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
}

这篇关于武力真的很糟糕，应该始终避免吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！