原文地址：http://www.cocoachina.com/ios/20171025/20906.html
在去年我应 IBM 编辑的邀请写过一篇关于Swift 2 中 throws 的文章。现在回头看，Swift 2 其实是 Swift 语言发展的一个挺重要的节点：如果说 Swift 1 是一个更偏向于验证阶段的产品的话，Swift 2 中加入的特性为这门语言的基石进行了补足。在那篇文章里我们主要深入探索了新的 throw 关键字背后的事情，而同一时期其实 Swift 官方有过一次关于错误处理的讨论。随着 Swift 3 的开源，这些原始文档也被一同公开，展示了 Swift 设计的过程和轨迹。如果你对这篇 Swift 2 中的错误处理的宣言感兴趣的话，可以在 GitHub 上 Swift 项目文档中找到原文。
最近参加了日本这边的一个社区办的 iOS 会议，其中koher给出了一个关于错误处理的 session，里面也提到了这篇文档，正确理解和思考 Swift 错误机制的类型非常有意思，它也可以指导我们在不同场景下对应使用正确的处理机制。
Swift 错误类型的种类
Simple domain error
简单的，显而易见的错误。这类错误的最大特点是我们不需要知道原因，只需要知道错误发生，并且想要进行处理。用来表示这种错误发生的方法一般就是返回一个 nil 值。在 Swift 中，这类错误最常见的情况就是将某个字符串转换为整数，或者在字典尝试用某个不存在的 key 获取元素：
| 1 2 3 4 5 | //SimpleDomainError的例子 letnum=Int( "helloworld" ) //nil letelement=dic[ "key_not_exist" ] //nil |
在使用层面 (或者说应用逻辑) 上，这类错误一般用 if let 的可选值绑定或者是 guard let 提前进行返回处理即可，不需要再在语言层面上进行额外处理。
Recoverable error
正如其名，这类错误应该是被容许，并且是可以恢复的。可恢复错误的发生是正常的程序路径之一，而作为开发者，我们应当去检出这类错误发生的情况，并进一步对它们进行处理，让它们恢复到我们期望的程序路径上。
这类错误在 Objective-C 的时代通常用 NSError 类型来表示，而在 Swift 里则是 throw 和 Error 的组合。一般我们需要检查错误的类型，并作出合理的响应。而选择忽视这类错误往往是不明智的，因为它们是用户正常使用过程中可能会出现的情况，我们应该尝试对其恢复，或者至少向用户给出合理的提示，让他们知道发生了什么。像是网络请求超时，或者写入文件时磁盘空间不足：
//网络请求 leturl=URL(string: "https://www.example.com/" )! lettask=URLSession.shared.dataTask( with :url){data,response,error in if leterror=error{ //提示用户 self.showErrorAlert( "Error:\(error.localizedDescription)" ) } letdata=data! //... } //写入文件 funcwrite(data:Data,tourl:URL){ do { try data.write(to:url) } catch leterror as NSError{ error.code==NSfileWriteOutOfSpaceError{ //尝试通过释放空间自动恢复 removeUnusedfiles() write(data:data,to:url) else { //其他错误，提示用户 showErrorAlert( ) } { ) } } |
Universal error
这类错误理论上可以恢复，但是由于语言本身的特性所决定，我们难以得知这类错误的来源，所以一般来说也不会去处理这种错误。这类错误包括类似下面这些情形：
//内存不足 [Int](repeating: 100 ,count:.max) //调用栈溢出 funcfoo(){foo()} foo() |
我们可以通过设计一些手段来对这些错误进行处理，比如：检测当前的内存占用并在超过一定值后警告，或者监视栈 frame 数进行限制等。但是一般来说这是不必要的，也不可能涵盖全部的错误情况。更多情况下，这是由于代码触碰到了设备的物理限制和边界情况所造成的，一般我们也不去进行处理（除非是人为造成的 BUG）。
在 Swift 中，各种被使用 fatalError 进行强制终止的错误一般都可以归类到 Universal error。
Logic failure
逻辑错误是程序员的失误所造成的错误，它们应该在开发时通过代码进行修正并完全避免，而不是等到运行时再进行恢复和处理。
常见的 Logic failure 包括有：
//强制解包一个`nil`可选值 var name: String ?=nil name! //数组越界访问 letarr=[ 1 2 3 ] letnum=arr[ ] //计算溢出 a=Int.max a+= 1 //强制try但是出现错误 !JsONDecoder().decode(Foo.self,from:Data()) |
这类错误在实现中触发的一般是 assert 或者 precondition。
断言的作用范围和错误转换
和 fatalError 不同，assert 只在进行编译优化的 -O 配置下是不触发的，而如果更进一步，将编译优化选项配置为 -Ounchecked 的话，precondition 也将不触发。此时，各方法中的 precondition 将被跳过，因此我们可以得到最快的运行速度。但是相对地代码的安全性也将降低，因为对于越界访问或者计算溢出等错误，我们得到的将是不确定的行为。
对于 Universal error 一般使用 fatalError，而对于 Logic failure 一般使用 assert 或者 precondition。遵守这个规则会有助于我们在编码时对错误进行界定。而有时候我们也希望能尽可能多地在开发的时候捕获 Logic failure，而在产品发布后尽量减少 crash 比例。这种情况下，相比于直接将 Logic failure 转换为可恢复的错误，我们最好是使用 assert 在内部进行检查，来让程序在开发时崩溃。
Quiz
光说不练假把式。让我们来实际判断一下下面这些情况下我们都应该选择用哪种错误处理方式吧~
#1 app 内资源加载
请听题。
假设我们在处理一个机器学习的模型，需要从磁盘读取一份预先训练好的模型。该模型以文件的方式存储在 app bundle 中，如果读取时没有找到该模型，我们应该如何处理这个错误？
方案 1 Simple domain error
funcloadModel()->Model?{ guardletpath=Bundle.main.path(forResource: "my_pre_trained_model" "mdl" ) { return nil } leturl=URL(fileURLWithPath:path) guardletdata= ?Data(contentOf:url) { nil } return ?ModelLoader.load(from:data) 方案 2 Recoverable error |
微信扫一扫
支付宝扫一扫
评论列表（0条）