【iOS 开发】NSError ** 与 throws 的三个问题

简介: 问题一:为什么有错误处理还要返回值?NSFileManager 里面有这样一个方法:- (BOOL)removeItemAtURL:(NSURL *)URL error:(NSError **)error;使用的时候我们会传入一个 &error...

问题一:为什么有错误处理还要返回值?

NSFileManager 里面有这样一个方法:

- (BOOL)removeItemAtURL:(NSURL *)URL error:(NSError **)error;

使用的时候我们会传入一个 &error 再获取这个错误值,来看这个过程中有没有什么错误,那么通过 error == nil 不就可以知道是否执行成功吗,为什么需要 BOOL 返回值,这是一个冗余的设计吗?

考虑下面这种情况:

NSData *data = nil;
NSError *error = nil;
BOOL success = [data writeToURL:nil options:NSDataWritingAtomic error:&error];

我们会发现,由于 data 是 nil,这个方法会直接返回 0,但是 error 依然是 nil,所以官方文档也要求我们一定要通过返回值判断是否执行成功,而不是仅仅去对 error 判空。

另外,基于 Objective-C 的语言特性,这里我们无法阻止调用者对 error 参数传递 nil,但是这个方法在这种情况下依然需要告知调用者是否执行成功,所以返回值是一个必要的设计。

然而,下面我们会发现,虽然这不是一个冗余设计,但是这也不是一个好的设计。


问题二:如何做出一个没有返回值的错误处理?

上面那个方法在 Swift 中是这样的:

func removeItem(atPath path: String) throws

没有返回值

Objective-C 中为了对外部创建的 NSError 赋值,使用了双指针设计,即 NSError *__autoreleasing*,这种做法在 Swift 语言中,变成了 inout 关键字:

func swapTwoInts(_ a: inout Int, _ b: inout Int) {
    let temporaryA = a
    a = b
    b = temporaryA
}

这实现了在函数中修改参数值,按照这种写法,是不是我们可以臆想出一种完全对应于 Objective-C 风格的版本:

func removeItem(atPath path: String) throws // 原版
func removeItem(atPath path: String, error: inout NSError) -> Bool // 臆想版本

理论上或许可行,但是这里我臆想出的这个版本,和 OC 中这个方法的设计,都是不好的设计:为了方便,很多时候开发者会对 error 传入
nil,这使得一旦出错,这里的 Error Handling 是无效的,而当初这里
传入 nil 也正是因为开发者认为这种同步方法不像异步的网络请求那样容易出错,最终就是艰难的 bug 排查。

Swift 2 引入的异常机制强迫我们使用下面的这种做法,

let fileManager = FileManager.default
do {
    try fileManager.removeItem(atPath: filePath)
} catch {
    print(error)
}

这样使得错误更加容易被发现和处理,并且由于 Swift 是强类型语言,在这里 nil 并不能执行 removeItem 方法,所以在这里,没有返回值却成了合理的设计。

但有一点需要注意,在这里我们只能获取到一个 error,我们却无法知道可以获取到一个什么样的 error,我们无法直接通过 API 知道,假如这里 removeItem 不成功,到底可能是因为什么样的原因而导致不成功。


问题三:throws 是同步的,异步的时候怎么办?

答:向 Error? 低头。

func dataTask(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTask

error An error object that indicates why the request failed, or nil if the request was successful.

由于 try catch 是一种同步的语法,在异步的时候,我们还是只能通过 Error 或者 NSError 来判断执行是否成功。

一种更好的做法其实是封装枚举,像这样:

enum JSONError: Error {
    case noSuchKey(String)
    case typeMismatch
}

对于这种做法可以参考 antitypical/Result,而如果你一定要使用原生 API,记得看一眼文档吧,到底 return value、error、responseData 中哪个值可以保证你的操作是成功的。


参考链接:

目录
相关文章
|
16天前
|
编解码 iOS开发 开发者
探索iOS开发中的SwiftUI框架
【5月更文挑战第31天】本文将深入探讨SwiftUI框架,这是Apple为iOS应用开发推出的最新用户界面工具包。我们将分析其核心概念、优势以及如何利用SwiftUI简化和加速开发流程,同时也会触及一些常见的挑战和解决方案。
|
1月前
|
前端开发 Android开发 iOS开发
【Flutter前端技术开发专栏】Flutter在Android与iOS上的性能对比
【4月更文挑战第30天】Flutter 框架实现跨平台移动应用,通过一致的 UI 渲染(Skia 引擎)、热重载功能和响应式框架提高开发效率和用户体验。然而,Android 和 iOS 的系统差异、渲染机制及编译过程影响性能。性能对比显示,iOS 可能因硬件优化提供更流畅体验,而 Android 更具灵活性和广泛硬件支持。开发者可采用代码、资源优化和特定平台优化策略,利用性能分析工具提升应用性能。
【Flutter前端技术开发专栏】Flutter在Android与iOS上的性能对比
|
2天前
|
安全 Android开发 iOS开发
探索Android与iOS开发的差异:平台特性与用户体验的对比分析
在移动应用开发的广阔天地中,Android和iOS两大阵营各据一方。本文将深入探讨这两个操作系统在开发环境、编程语言、用户界面设计及市场分布等方面的主要区别。通过比较分析,我们将揭示各自平台的特有优势,并讨论如何根据目标受众和业务需求选择适合的开发平台。
|
2天前
|
iOS开发 开发者
探索iOS开发中的SwiftUI框架
【6月更文挑战第14天】本文将深入探讨iOS开发领域的新星——SwiftUI框架。我们将从其设计理念出发,逐步解析其结构与核心组件,并通过实例展示如何利用SwiftUI简化界面构建流程,提升开发效率。同时,我们也将讨论SwiftUI在现有项目中的集成策略及其对iOS应用开发未来的可能影响。
8 1
|
3天前
|
安全 Java Android开发
探索Android与iOS开发的差异与挑战
在移动应用开发的广阔天地里,Android和iOS两大平台各自占据半壁江山。本文将深入探讨这两个平台的开发环境、工具、语言以及设计理念的差异,并分析这些差异给开发者带来的挑战。我们将从多个角度出发,包括用户界面设计、性能优化、安全性考量、以及市场分布等方面,为读者提供一个全面的视角,以理解在这两个平台上进行开发时需要考虑的关键因素。
|
3天前
|
Swift iOS开发 开发者
探索iOS开发中的SwiftUI框架
【6月更文挑战第13天】本文将深入探讨iOS开发中的一个重要工具——SwiftUI框架。我们将了解其基本概念,如何在实际项目中应用,以及它为开发者带来的优势和挑战。
|
5天前
|
iOS开发 开发者 UED
探索iOS开发中的SwiftUI框架
在移动应用开发的广阔天地中,苹果公司的SwiftUI框架以其声明式语法和直观布局管理,为iOS开发者带来了新的生产力工具。本文将深入探讨SwiftUI的设计哲学、核心概念以及在实际项目中如何高效运用该框架,旨在为读者提供一份全面的SwiftUI使用指南。
|
5天前
|
API Swift iOS开发
探索iOS开发中的SwiftUI框架
【6月更文挑战第11天】本文将深入探讨iOS开发中的一个重要工具——SwiftUI框架。我们将了解其基本概念,如何在实际项目中应用,以及它如何改变iOS应用的开发方式。
|
6天前
|
编解码 安全 Android开发
探索iOS与Android开发的差异:从界面到性能
【6月更文挑战第10天】在移动应用开发的广阔天地中,iOS和Android两大平台各占山头,它们在设计理念、用户体验、性能优化等方面展现出独特的魅力。本文将深入探讨这两大系统在开发过程中的主要差异,从用户界面设计到性能调优,揭示各自背后的技术逻辑与创新策略,为开发者提供全面的视角和实用的开发指南。
|
6天前
|
Android开发 Swift iOS开发
探索安卓与iOS开发的差异性
【6月更文挑战第9天】本文深入探讨了安卓和iOS这两大主流移动操作系统在应用程序开发方面的关键差异。从编程语言、用户界面设计到市场策略,我们将逐一分析这些差异如何影响开发者的选择和最终产品的用户体验。通过比较,我们旨在为开发者提供一份实用的指南,帮助他们在这两个平台上做出更明智的开发决策。