数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

关于 Swift Error 的分类

在去年我应 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 获取元素:

// Simple Domain Error 的例子

let num = Int("hello world") // nil

let element = dic["key_not_exist"] // nil

在使用层面 (或者说应用逻辑) 上,这类错误一般用 if let 的可选值绑定或者是 guard let 提前进行返回处理即可,不需要再在语言层面上进行额外处理。

Recoverable error

正如其名,这类错误应该是被容许,并且是可以恢复的。可恢复错误的发生是正常的程序路径之一,而作为开发者,我们应当去检出这类错误发生的情况,并进一步对它们进行处理,让它们恢复到我们期望的程序路径上。

这类错误在 Objective-C 的时代通常用 NSError 类型来表示,而在 Swift 里则是 throw 和 Error 的组合。一般我们需要检查错误的类型,并作出合理的响应。而选择忽视这类错误往往是不明智的,因为它们是用户正常使用过程中可能会出现的情况,我们应该尝试对其恢复,或者至少向用户给出合理的提示,让他们知道发生了什么。像是网络请求超时,或者写入文件时磁盘空间不足:

// 网络请求
let url = URL(string: "https://www.example.com/")!
let task = URLSession.shared.dataTask(with: url) { data, response, error in
    if let error = error {
        // 提示用户
        self.showErrorAlert("Error: \(error.localizedDescription)")
    }
    let data = data!
    // ...
}

// 写入文件
func write(data: Data, to url: URL) {
    do {
        try data.write(to: url)
    } catch let error as NSError {
        if error.code == NSFileWriteOutOfSpaceError {
            // 尝试通过释放空间自动恢复
            removeUnusedFiles()
            write(data: data, to: url)
        } else {
            // 其他错误,提示用户
            showErrorAlert("Error: \(error.localizedDescription)")
        }
    } catch {
        showErrorAlert("Error: \(error.localizedDescription)")
    }
}

Universal error

这类错误理论上可以恢复,但是由于语言本身的特性所决定,我们难以得知这类错误的来源,所以一般来说也不会去处理这种错误。这类错误包括类似下面这些情形:

// 内存不足
[Int](repeating: 100, count: .max)

// 调用栈溢出
func foo() { foo() }
foo()

我们可以通过设计一些手段来对这些错误进行处理,比如:检测当前的内存占用并在超过一定值后警告,或者监视栈 frame 数进行限制等。但是一般来说这是不必要的,也不可能涵盖全部的错误情况。更多情况下,这是由于代码触碰到了设备的物理限制和边界情况所造成的,一般我们也不去进行处理(除非是人为造成的 bug)。

在 Swift 中,各种被使用 fatalError 进行强制终止的错误一般都可以归类到 Universal error。

Logic failure

逻辑错误是程序员的失误所造成的错误,它们应该在开发时通过代码进行修正并完全避免,而不是等到运行时再进行恢复和处理。

常见的 Logic failure 包括有:

// 强制解包一个 `nil` 可选值
var name: String? = nil
name!

// 数组越界访问
let arr = [1,2,3]
let num = arr[3]

// 计算溢出
var a = Int.max
a += 1

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
关于 Swift Error 的分类
发布:2017-10-25

在去年我应 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 获取元素:

// Simple Domain Error 的例子

let num = Int("hello world") // nil

let element = dic["key_not_exist"] // nil

在使用层面 (或者说应用逻辑) 上,这类错误一般用 if let 的可选值绑定或者是 guard let 提前进行返回处理即可,不需要再在语言层面上进行额外处理。

Recoverable error

正如其名,这类错误应该是被容许,并且是可以恢复的。可恢复错误的发生是正常的程序路径之一,而作为开发者,我们应当去检出这类错误发生的情况,并进一步对它们进行处理,让它们恢复到我们期望的程序路径上。

这类错误在 Objective-C 的时代通常用 NSError 类型来表示,而在 Swift 里则是 throw 和 Error 的组合。一般我们需要检查错误的类型,并作出合理的响应。而选择忽视这类错误往往是不明智的,因为它们是用户正常使用过程中可能会出现的情况,我们应该尝试对其恢复,或者至少向用户给出合理的提示,让他们知道发生了什么。像是网络请求超时,或者写入文件时磁盘空间不足:

// 网络请求
let url = URL(string: "https://www.example.com/")!
let task = URLSession.shared.dataTask(with: url) { data, response, error in
    if let error = error {
        // 提示用户
        self.showErrorAlert("Error: \(error.localizedDescription)")
    }
    let data = data!
    // ...
}

// 写入文件
func write(data: Data, to url: URL) {
    do {
        try data.write(to: url)
    } catch let error as NSError {
        if error.code == NSFileWriteOutOfSpaceError {
            // 尝试通过释放空间自动恢复
            removeUnusedFiles()
            write(data: data, to: url)
        } else {
            // 其他错误,提示用户
            showErrorAlert("Error: \(error.localizedDescription)")
        }
    } catch {
        showErrorAlert("Error: \(error.localizedDescription)")
    }
}

Universal error

这类错误理论上可以恢复,但是由于语言本身的特性所决定,我们难以得知这类错误的来源,所以一般来说也不会去处理这种错误。这类错误包括类似下面这些情形:

// 内存不足
[Int](repeating: 100, count: .max)

// 调用栈溢出
func foo() { foo() }
foo()

我们可以通过设计一些手段来对这些错误进行处理,比如:检测当前的内存占用并在超过一定值后警告,或者监视栈 frame 数进行限制等。但是一般来说这是不必要的,也不可能涵盖全部的错误情况。更多情况下,这是由于代码触碰到了设备的物理限制和边界情况所造成的,一般我们也不去进行处理(除非是人为造成的 bug)。

在 Swift 中,各种被使用 fatalError 进行强制终止的错误一般都可以归类到 Universal error。

Logic failure

逻辑错误是程序员的失误所造成的错误,它们应该在开发时通过代码进行修正并完全避免,而不是等到运行时再进行恢复和处理。

常见的 Logic failure 包括有:

// 强制解包一个 `nil` 可选值
var name: String? = nil
name!

// 数组越界访问
let arr = [1,2,3]
let num = arr[3]

// 计算溢出
var a = Int.max
a += 1

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

选择想要的接口, 看看能免费获取多少次调用 选择(单选)或填写想要的接口
  • 短信API服务
  • 银行卡四元素检测[简]
  • 身份证实名认证
  • 手机状态查询
  • 三网手机实名制认证[简]
  • 身份证OCR识别
  • 风险信息查询
  • 企业工商信息
短信API服务
  • 短信API服务
  • 银行卡四元素检测[简]
  • 身份证实名认证
  • 手机状态查询
  • 三网手机实名制认证[简]
  • 身份证OCR识别
  • 风险信息查询
  • 企业工商信息
  • 确定
选择您的身份
请选择寻找接口的目的
预计每月调用量
请选择预计每月调用量
产品研发的阶段
请选择产品研发的阶段
×
企业用户认证,
可获得1000次免费调用
注册登录 > 企业账户认证 > 领取接口包
企业用户认证领取接口包 立即领取
× 企业用户认证,
可获得1000次免费调用,立即领取>
数 据 驱 动 未 来
Data Drives The Future