教程文档【免费下载链接】Awesome-Swift-Education:fire: Learn some Swift项目地址https://gitcode.com/gh_mirrors/aw/Awesome-Swift-Education点击查看免费下载本指南以开源仓库 Awesome-Swift-Education 中 Swift /Error Handling/ErrorHandling.md 学习清单为骨架系统梳理 Swift 错误处理的五大支柱以guard为代表的早期返回、以throws为标志的失败声明、以do-catch为入口的错误消费、以assert/precondition为手段的开发期校验以及以ErrorType/Result为载体的类型化错误建模。读完本文你将掌握 Swift 2 时代奠基、至今仍在演进的核心错误处理语法与设计取舍并能在真实项目中为函数何时该抛错、如何抛、如何接、如何断言做出有依据的决策。1. 为什么需要一个错误处理专题页在 Swift 语言体系中错误处理不是孤立的语法糖而是贯穿函数声明、控制流、可选类型与类型系统的一条主线。Awesome-Swift-Education 仓库在 Swift /Error Handling/ErrorHandling.md 中专门开辟了一节按Guard、Throw、try / catch、Asserts、ErrorType、Other六个子主题组织资源恰好对应 Swift 错误处理的完整闭环预防——用guard在入口处拦截非法状态避免深层嵌套声明——用throws明确告知调用方这个函数可能失败消费——用try/catch或try?/try!决定失败如何被处理校验——用assert/precondition在开发期暴露程序逻辑错误建模——用ErrorType协议与ResultT, E把失败本身变成类型系统可以表达和组合的值。需要说明的是该文档汇编于 Swift 2.x 时期2015–2016 年正文代码示例以 Swift 2 语法为基准后文凡涉及版本演进如ErrorType更名为Error都会明确标注便于你对照当前 Swift 版本阅读。2. Guard把验证写在前面的早期返回guard是 Swift 错误预防的第一道防线。它的核心价值在于翻转控制流与其用多层if嵌套把正常路径越包越深不如用guard把异常路径在函数开头一次性排除让正常代码保持平铺直叙。2.1 guard 与 if 的本质差异guard与if最大的不同在于语义方向guard要求条件必须成立否则立即退出当前作用域因此else分支必须包含return、break、continue或throw等跳出语句编译器会强制检查这一点。这一设计消除了if 嵌套金字塔也杜绝了忘了 return 导致继续执行非法代码的隐患。// 糟糕深层嵌套 func process(user: User?) { if let user user { if user.isValid { if let name user.name { print(Hello, \(name)) } } } } // 更好guard 平铺 func process(user: User?) { guard let user user else { return } guard user.isValid else { return } guard let name user.name else { return } print(Hello, \(name)) }第二版代码中每一次guard都明确表达了这条路上有一个前置条件不满足就停在这里可读性和可维护性都显著提升。这也是文档中The Value of Guardguard 的价值与guard is better than ifguard 优于 if两个条目的核心论点。2.2 何时用 guard、何时不要用文档专门列出了When to (not) use guard何时使用、何时不要使用 guard其讨论要点可以归纳为三条实用准则用 guard 的场景函数需要多个前置条件才能继续、每次失败都需要提前退出、以及需要在作用域内保留解包后的常量guard let解绑的可选项在整个作用域内都可用而if let解绑的常量只在 if 块内有效不用 guard 的场景只有一个可选判断且后续逻辑需要同时处理成功与失败两个分支此时if-else更直白或者失败后并不想退出作用域而是想继续走同一条路径此时应使用if注意争议文档收录了社区中guard 应当被避免及其反驳文章RE: Why Swift Guard Should Be Avoided。这类讨论的核心并非 guard 本身有错而是提醒开发者不要机械地把所有 if 都改成 guard——guard 的适用前提是失败即退出如果退出条件设计不当反而会掩盖错误的层级与位置。2.3 三个让 guard 更简洁的实践技巧文档收录的Three tips for concise Swift using the Guard statement总结的常见简洁化手法包括合并条件多个互不相关的布尔条件可以写在同一个guard中用逗号分隔等价于减少重复的else { return }guard isLoggedIn, hasValidToken, userID ! nil else { return }让 guard 只做检查guard的else分支应当保持精简一句 return / throw不要在else里塞入复杂逻辑否则就违背了前置条件校验的初衷组合guard let与附加条件在解绑的同时继续校验例如guard let json try? JSONSerialization.jsonObject(with: data), let dict json as? [String: Any], let id dict[id] as? Int else { return }2.4 guard 与 defer 的搭配文档将Guard and Defer作为一个独立条目列出正是因为两者经常成对出现guard负责提前退出defer负责退出前必须做的事。例如一个需要释放锁或关闭文件的函数func withLockedResource() throws { lock.lock() defer { lock.unlock() } // 无论正常返回还是 throw都会执行 guard let resource try fetchResource() else { return } // ...使用 resource }guard让多个退出点变得合法defer则保证每个退出点都不会漏掉清理工作——两者的组合是 Swift 中安全提前返回的标准范式。3. Defer作用域退出时的确定性清理defer是文档在 Guard 子主题下重点介绍的另一机制。它的语义是把一段代码的执行推迟到当前作用域退出之时无论退出是正常 return、throw、break 还是程序流程自然结束。3.1 defer 的执行时机与顺序func example() { defer { print(first defer) } defer { print(second defer) } print(body) } // 输出顺序body - second defer - first defer要点defer块在当前作用域结束前执行但具体时机是所有defer语句注册之后、作用域真正退出之前多个defer按LIFO后进先出顺序执行即后注册的先执行defer的作用范围是它所在的词法作用域函数体、循环体、do块等退出该作用域即触发。3.2 defer 的典型应用文档条目Defer in Swift覆盖的典型场景包括资源释放文件句柄、数据库连接、dispatch_semaphore信号量等必须在函数退出时无条件释放锁的成对加解锁避免提前return导致死锁性能测量在函数开头注册defer { stopMeasuring() }无论哪个分支返回都能记录耗时状态恢复修改了某个全局状态如UIApplication.shared.isNetworkActivityIndicatorVisible true后在退出时恢复。需要留意的是defer块中不应包含会改变控制流的语句如return因为作用域已经决定退出defer 中的返回意图没有意义。4. Throw声明这个函数会失败如果说guard是防御那么throws就是契约。文档以Let it Throw!为标题的条目强调的核心观点是不要让错误被静默吞掉让它通过函数签名显式地传播出去。4.1 throws 函数与 throw 语句enum FileError: ErrorType { case NotFound case PermissionDenied } func readFile(at path: String) throws - String { guard fileExists(at: path) else { throw FileError.NotFound // 声明失败 } guard canRead(at: path) else { throw FileError.PermissionDenied } return contents(of: path) // 正常返回 }一个函数只要在签名中标注throws内部就可以用throw抛出任意符合ErrorType的值调用方必须显式处理这种可能失败编译器会强制检查throws与返回值可以并存throws - String表示要么返回 String要么抛出错误。4.2 Throws 就像 Either 类型文档用一个比喻Throws is like an Either Type帮助理解EitherError, T类型显式地表达这个计算要么是错误Left要么是成功值Right。而throws - T在语义上与之等价——函数的返回类型是T或错误只是错误通过异常通道传递而非通过返回值传递。这个视角的价值在于它提醒你throws 是返回类型的一部分设计函数时要把失败当成一等公民来设计它也解释了为什么许多函数式风格的 Swift 代码倾向用ResultT, E替代 throws详见第 8 节因为把错误作为值返回可以让错误参与 map/flatMap 等组合运算。4.3 Throwing vs failing vs crashing vs bool四种失败模式文档列出的Throwing vs failing vs crashing vs bool讨论实际上是在帮开发者回答失败应该用哪种方式表达方式语义适用场景throw函数显式失败调用方必须处理业务规则不满足、外部资源不可用等可预期且需要调用方决策的错误返回Bool只表达成功/失败两种结果不携带细节校验类、过滤类逻辑调用方只关心过没过返回Optional失败时返回nil语义为没有结果查找、解析等失败即无值的场景详见 Swift /Optionals/Optionals.md直接崩溃crash / fatalError / 强制解包失败程序状态已不可恢复程序员逻辑错误、不可能出现的先决条件被违反判断准则可以概括为错误越可恢复、需要调用方决策越应该用 throw错误越不可恢复、属于程序 bug越应该用断言或崩溃第 7 节会展开。不要把所有失败都抛成异常也不要用Bool掩盖错误的细节信息。4.4 throws 与 completion callback 的配合异步场景下throws无法直接跨线程传播回调函数无法向调用栈上层抛错文档的Using Swift Throws with Completion Callbacks条目给出的是经典解法把错误放入回调参数。// 同步throws 传播 func fetchSync() throws - Data // 异步错误作为回调参数 func fetchAsync(completion: (ResultData, ErrorType) - Void) { DispatchQueue.global().async { // 成功completion(.Success(data)) // 失败completion(.Failure(error)) } }这种模式把错误从异常通道转移到值通道与第 8 节的Result建模殊途同归——这也是为什么异步错误处理见第 9 节在 Swift 社区长期是热点话题。4.5 rethrows闭包抛错时的再抛出文档单独列出Rethrows in Swift 2。rethrows适用于以闭包为参数、且闭包可能 throws 的高阶函数语义是这个函数本身不抛出错误但它的闭包参数如果抛错错误会继续向上传播。// map 内部不抛错但 closure 可以抛所以整体声明为 rethrows func myMapT, U(_ items: [T], transform: (T) throws - U) rethrows - [U] { var result: [U] [] for item in items { result.append(try transform(item)) } return result } // 传入不抛错的闭包时调用方无需 try传入 throws 闭包时调用方必须 try let doubled myMap([1, 2, 3]) { $0 * 2 } // 无需 try let parsed try myMap([1, 2]) { try parse($0) } // 需要 tryrethrows的精妙之处在于让可能失败性随闭包类型传递闭包不抛错调用点就不必写try接口更干净闭包抛错错误也不会被吞掉。map、filter、forEach等标准库高阶函数均采用这一声明。仓库中 Swift /Closures Functions/ClosuresFunctions.md 收录的noreturn条目标注永不返回的函数如fatalError与此同属函数失败/终止行为的签名级表达可一并参考。5. try/catch消费错误throws声明了会失败try与catch则负责消费失败。Swift 的do-catch结构把错误处理显式地写入控制流这是文档try/catch with asynchronous closures、do-try-catch syntax与try, catch, do and throw几个条目共同覆盖的语法核心。5.1 基本形态do-catchdo { let content try readFile(at: /etc/hosts) print(content) } catch FileError.NotFound { print(文件不存在) } catch FileError.PermissionDenied { print(没有权限) } catch { print(其他错误\(error)) }语法要点所有可能抛出错误的调用前必须写trycatch可以按具体错误类型/模式匹配从上到下逐一尝试兜底的catch无模式会绑定一个隐式常量error若do块内某个try抛错控制流立即跳到匹配的catch块内后续代码不再执行。5.2 catch 的模式匹配能力catch本质上是模式匹配因而可以配合 Swift 强大的模式语法do { try dangerousOperation() } catch let error as NetworkError where error.isRetryable { retry() } catch NetworkError.Timeout { print(超时) } catch let error { print(未知错误\(error)) }文档在Other部分收录的Swift 2 Error Handling控制流条目正是讨论do-catch与switch在模式匹配上的相似性——如果你熟悉switch的case语法就能无缝迁移到catch上。5.3 try 的三种形态try、try?、try!文档专门列出What Is the Difference Between try, try?, and try!这是每个 Swift 开发者都必须精确掌握的区分形态行为适用场景try必须位于do-catch或throws函数内错误由catch或上层函数处理需要针对错误类型做分支处理、或需要向上传播try?成功返回OptionalT失败返回nil错误被吞掉不进入 catch只关心有没有结果失败即nil与可选绑定天然配合try!成功返回T失败直接崩溃你百分之百确定不会失败如读取硬编码的合法 JSON失败即视为程序 bug// try?失败变成 nil let data1 try? readFile(at: path) // String? 类型 guard let content try? readFile(at: path) else { return } // try!绝不失败失败即崩溃 let data2 try! readFile(at: knownGoodPath) // String 类型使用建议优先try保留错误信息其次try?错误不关心try!仅限失败在逻辑上不可能的场合——它与强制解包!一样是把程序 bug转换成崩溃的手段。文档中do or die条目的讨论也与这一取舍相关与其让错误在运行时或死或生地靠运气不如尽量用类型把失败编码为可预期的值。6. 异步闭包中的 try/catch文档的try/catch with asynchronous closures条目提醒了一个重要陷阱do-catch只能捕获当前同步执行上下文中的错误无法捕获异步回调中抛出的错误。// 错误示范catch 捕获不到闭包内抛出的错误 do { DispatchQueue.global().async { try self.performNetworkCall() // 编译错误或错误逃逸 } } catch { // 永远不会执行 }正确做法是把错误传回异步边界回调参数或Resultfunc performAsync(completion: (ResultData, ErrorType) - Void) { DispatchQueue.global().async { do { let data try self.performNetworkCall() completion(.Success(data)) } catch { completion(.Failure(error)) } } }这一模式是 Swift 异步错误处理的基础共识也是第 9 节异步错误处理进阶主题的前提。7. Asserts 与 precondition开发期校验与运行期守卫错误处理的前四个支柱解决可恢复错误而assert/precondition解决**不可恢复的程序逻辑错误**——它们不属于业务失败而是代码 bug 的早期暴露。文档在Asserts子主题下列出了Swift assertions、Using the assert() keywordassert 缺失手册、Assert vs precondition等多个条目。7.1 assert 与 assertionFailurelet index 5 assert(index array.count, 索引越界) // 条件为假时触发 assertionFailure(此处代码不应被执行到) // 无条件触发关键特性assert仅在Debug调试构建中生效Release 构建会被编译器移除不产生运行时开销它表达的是开发期帮我验证我的假设适合校验不变量、前置条件等纯开发期检查条件为假时触发程序终止并打印消息Xcode 中会停在断点处。7.2 precondition 与 assert 的区别文档的Assert vs precondition条目正是为了厘清这对易混淆的兄弟。核心区别在生效范围函数Debug 构建Release 构建适用场景assert生效不生效被移除纯开发期假设验证precondition生效依然生效无论什么构建都必须成立的前置条件如下标必须合法fatalError生效生效无条件终止如noreturn场景// 即便发布版数组下标也绝不能越界——用 precondition 而非 assert precondition(index 0 index array.count, 下标越界)判断准则如果条件失败意味着这个程序在发布版也不该继续运行用precondition如果只是开发期帮我排查问题用assert。仓库中 Swift /Debugging/Debugging.md 与 Swift /Testing/Testing.md 分别从调试与测试角度与本节呼应测试框架中的XCTAssert*家族即断言思想在单元测试中的延伸。8. ErrorType把错误建模成类型Swift 2 中所有错误都必须符合ErrorType协议Swift 3 起更名为Error。文档的ErrorType子主题含Swift 2: Error handling using ErrorType, throws, try and do-catch与Testing Swifts ErrorType展示了这一建模思想。8.1 用枚举建模错误域ErrorType的核心用法是用枚举把一类错误的所有可能情况枚举出来让错误成为可模式匹配、可穷举的类型enum NetworkError: ErrorType { case Timeout case ServerError(code: Int) case NoConnection } func fetchUser() throws - User { guard isConnected else { throw NetworkError.NoConnection } // ... throw NetworkError.ServerError(code: 500) }枚举错误相比字符串/整数错误码的优势类型安全编译器知道全部可能的错误情况catch可穷举可携带数据关联值如code: Int让错误自带上下文可模式匹配catch NetworkError.ServerError(let code) where code 500这类写法成为可能。8.2 测试错误处理逻辑文档的Testing Swifts ErrorType强调错误路径与正常路径一样需要单元测试。典型做法是断言调用确实抛出了预期错误func testFetchThrowsOnNoConnection() { // 关闭网络后调用 fetchUser断言抛出 NetworkError.NoConnection // Swift 2 时代常见做法用 do-catch 捕获并匹配错误类型 }8.3 ResultT, E成功/失败的类型化建模文档在 ErrorType 子主题下特别收录了Resultantitypical/Result库并将其描述为Swift type modelling the success/failure of arbitrary operations——一个建模任意操作成功/失败的 Swift 类型。其核心形态是一个泛型枚举enum ResultT, E { case Success(T) case Failure(E) }Result的价值在于把错误放回值通道函数签名直接体现可能失败无需throws失败值可以像普通值一样被存储、传递、组合map/flatMap天然适配异步回调见 4.4 节与函数式编程风格。这一思想与仓库中 Swift /Functional Programming/FunctionalProgramming.md 的 Monad 主题一脉相承——Result以及Either是用类型表达计算可能失败的典型函数式建模文档Swift 2 Error Handling vs ResultT, E条目正是对比异常通道throws与值通道Result两条路线的取舍前者语法内建、控制流显式后者可组合、可存储、对异步友好。需要说明的是随着 Swift 5 将Result引入标准库并推出async/await这两种思路在现代 Swift 中已趋于融合但理解其设计差异仍是阅读历史代码与设计新 API 的重要基础。9. 进阶主题文档 Other 部分的完整继承原文档在Other子主题下列出的条目构成错误处理的延伸视野逐条展开如下。9.1 异步错误处理Async Error Handling异步错误无法用同步的do-catch捕获见第 6 节社区给出的演进路线是completion callback Result→ Promise/Future 风格封装 → 语言级async/await。无论哪一代方案核心不变错误必须穿过异步边界且不应丢失类型信息。9.2 错误分类学unexpected、composite、non-pure、external文档收录的Errors: unexpected, composite, non-pure, external提出了一种错误分类框架值得在设计错误类型时参考unexpected意外错误不可预测、通常也不可恢复如内存问题往往对应崩溃而非 throwcomposite复合错误多个错误叠加如批量任务中部分失败需要聚合建模non-pure非纯错误函数不仅返回错误还产生了副作用如部分写入了数据库错误处理必须考虑已执行的副作用external外部错误源自函数外部环境网络、磁盘、用户输入是 throws 的主要用武之地。9.3 Unmanaged Type文档收录的Unmanaged Type条目属于错误处理的边缘话题UnmanagedT用于手动管理 Core Foundation 对象的引用计数绕过 ARC 的自动管理。当手动释放内存的时机出现错误时容易产生内存安全问题——它提醒我们底层资源错误是错误处理中风险最高的一类。9.4 Error Styling in SwiftError Styling in Swift讨论的是错误消息的表达风格错误文案如何写才便于用户理解与调试包括错误枚举的命名、关联值携带的上下文、CustomStringConvertible输出的可读性等。实践要点是错误类型要具体不要一律Error.generic消息要可操作告诉调用方下一步能做什么。9.5 Magic Methods in Swift文档收录 Apple 官方 Swift 博客的Magic Methods in Swift条目。它虽然不直接讲 throw但与错误处理相关Swift 中try/catch/defer等魔法方法由编译器提供语法支持理解它们的底层语义如 defer 的作用域规则、throws 的错误通道有助于避免误用。9.6 Swift 2 Error Handling 总览与社区实践文档Other部分还收录了三类补充材料可视为对第 1–8 节的整体回顾入门总览Error Handling in Swift、Easy Error Handling、Swift 2 Error HandlingBig Nerd Ranch等条目覆盖从零开始的完整教程对比视角Swift 2 Error Handling vs ResultT, E、Monad/Either相关讨论帮助你理解类型化错误与异常通道的关系实战分享Three Stories of Error Handling in Swifttry!Swift 社区演讲通过真实项目案例讲述错误处理设计的演进与教训——社区共识是错误类型设计要与业务域对齐错误路径与正常路径同样需要测试覆盖。10. 仓库导航如何在 Awesome-Swift-Education 中继续深入本文对应的原始学习清单位于 Swift /Error Handling/ErrorHandling.md与仓库其他章节构成完整的 Swift 学习地图语言基础延伸Swift /Optionals/Optionals.md可选类型的解包与 guard 密切相关、Swift /Closures Functions/ClosuresFunctions.mdnoreturn、闭包与 rethrows 的承接关系、Swift /Enums and Pattern Matching/EnumsPatternMatching.md错误枚举与 catch 模式匹配的基础工程实践延伸Swift /Testing/Testing.md错误路径的单元测试、Swift /Debugging/Debugging.md断言与崩溃的排查、Swift /Functional Programming/FunctionalProgramming.mdResult/Monad 的函数式背景、Swift /Design Patterns/DesignPatterns.md错误处理相关的模式设计仓库动态README.md 概括了仓库定位Learn some SwiftMostRecentAdditions.md 记录了持续更新的资源其中try, try! try?、do-try-catch syntax、ErrorType、Three Stories of Error Handling等条目与本文主题直接相关Contributing.md 说明了贡献方式。11. 小结Swift 错误处理决策速查把本文全部内容压缩为一张决策表供日常编码快速对照场景推荐手段关键理由函数入口有多个前置条件guard ... else { return }平铺控制流解绑常量作用域更大需要退出作用域前清理资源defer无论 return/throw 都保证执行LIFO 顺序业务失败需要调用方决策throwsErrorType枚举类型安全、可穷举、可模式匹配异步回调中传播失败回调携带ResultT, E错误跨异步边界可组合只想关心有没有结果try?失败变nil配合可选绑定失败在逻辑上不可能try!失败即视为 bug直接崩溃暴露开发期验证假设assertDebug 有效、Release 零开销发布版也必须满足的前置条件precondition任何构建都生效把失败作为值参与组合ResultT, Emap/flatMap 组合函数式友好Swift 的错误处理体系是一套预防guard— 声明throws— 消费try/catch— 校验assert— 建模ErrorType/Result的完整闭环。以 Swift /Error Handling/ErrorHandling.md 为索引、以本文为导览你可以沿着这条主线逐步构建自己的错误处理方法论——先让函数诚实地声明失败再让调用方有选择地处理失败最后让错误本身成为类型系统里可组合、可测试、可对话的一等公民。赞分享教程文档【免费下载链接】Awesome-Swift-Education:fire: Learn some Swift项目地址https://gitcode.com/gh_mirrors/aw/Awesome-Swift-Education点击查看免费下载相关推荐Swift-Paperless终极指南在iOS上轻松管理您的纸质文档Swift Paperless终极指南在iOS上轻松管理您的纸质文档 想要随时随地管理您的数字文档吗Swift Paperless是专为PaperlessSwift 错误处理完全指南throw、do-catch、try?/try! 与类型化抛错实战解析《Swift 编程语言》中文版Swift 错误处理完全指南throw、do catch、try?/try! 与类型化抛错实战解析《Swift 编程语言》中文版 Swift 的错误处理机文档教程Bark-server完全指南如何在5分钟内搭建专属iOS推送服务器Bark server完全指南如何在5分钟内搭建专属iOS推送服务器 想要为自己的iOS应用搭建专属推送服务器吗Bark server就是你的终极解决方案上一篇构建高效工业数据采集系统的5种实践方案libiio跨平台技术深度解析下一篇告别白屏vue2-happyfri服务端渲染实战3步提升移动端首屏速度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考