Swift：NSError现在应该被认为是遗产吗？

文档和流行的博客建议使用do-catch完成Swifterror handling，并处理ErrorType枚举或NSError实例。

在try catch块中，ErrorType枚举和NSError实例是否互斥？ 如果没有，你如何实现抛出两者的function？

我已经将一个NSError实例关联到这样的枚举，这似乎有效，但这是返回详细错误信息的事实上的方法吗？

enum Length : ErrorType { case NotLongEnough(NSError) case TooLong(NSError) } func myFunction() throws { throw Length.NotLongEnough(NSError(domain: "domain", code: 0, userInfo: [NSLocalizedFailureReasonErrorKey: "Not long enough mate"])) } do { try myFunction() } catch Length.NotLongEnough(let error) { print("\(error)") } 

此示例显示如何将ErrorType强制转换为NSError。

 do { let str = try NSString(contentsOfFile: "Foo.bar", encoding: NSUTF8StringEncoding) } catch let error as NSError { print(error.localizedDescription) } 

我找不到符合NSString的ErrorType的错误枚举，所以我们应该假设它是一个NSError实例吗？ 当然，我们可以运行代码以确保，但文档应该让我们知道。 （我很欣赏我可能会误读文档）

Answer 1

NSError类采用ErrorType接口，任何ErrorType -conformant类都可以转换为NSError 。 这些function在文档中有所描述。

您可以安全地坚持使用ErrorType ，特别是如果您计划仅与Swift进行互操作。

 enum CommonError: ErrorType { case InternalInconsistency(String) } func boom() throws { throw CommonError.InternalInconsistency("Boom!") } do { try boom() } catch { print(error) // InternalInconsistency("Boom!") print(error as NSError) // Error Domain=CommonError Code=0 "(null)" } do { try boom() } catch let CommonError.InternalInconsistency(msg) { print("Error: \(msg)") // Error: Boom! } 

Answer 2

任何ErrorType都可以成功转换为NSError ，这意味着如果您想将ErrorType作为优先级或特定的ErrorType符合Swift类型处理，那么在您转换为NSError情况之前应该有这些情况（这将再次成功对于所有ErrorType一致的ant类型）。

我不确定Apple现阶段是否有关于如何处理这种二元性的任何规范性观点，但我个人试图坚持ErrorType符合Swift类型的ErrorType来解决我自己的错误，并且只涉及在我使用时转换为NSError想要根据一些Cocoa或第三方基于NSError的代码进行条件行为，其中域和代码组合对我的逻辑有某种意义（例如，如果特定错误可以从日志记录或响应中过滤掉）。

Swift中用于error handling的现有工具的问题主要是由于无法分辨方法引发的错误类型， ErrorType缺少ErrorType包含的一些关键上下文信息的ErrorType ，每次您想要呈现时都会提供额外的定制工作UI中的ErrorType s以某种方式提供给用户。 与NSError不同，ErrorType没有办法传递UI预期信息，例如“原因”或“恢复建议”，或者实际上是“描述”。 对于Swift 3来说，这似乎还没有得到解决（最近在Swift开发邮件列表上对此进行了一些讨论）。

关于“我找不到符合NSString的ErrorType的错误枚举”我真的不确定我是否正确理解了这个短语或者整体上是否措辞正确，但可能以下内容是相关的：

我个人遵循制定我的ErrorType实现CustomStringConvertible的惯例，并使用description属性来描述错误的人类（UI预期）可读描述。 这绝不是完美的，特别是在OSX上， NSResponder很好地为你提供了presentError方法，如果你填写描述和恢复建议信息，它会产生一个非常好的和清晰的错误对话框。