Swift的错误处理模型是对C++异常的不可见控制流跳转和Java检查异常的官僚式僵化的直接反应。传统异常处理的根本问题在于，throw 语句可以在没有中间调用点的语法标记的情况下跨多个堆栈帧传递控制，这使得代码审查和静态分析变得不可靠。Swift通过将错误视为第一类返回值来解决这个问题，使用标记联合表示法，其中 try 关键词作为编译时强制的注释，使得源代码中的潜在退出点变得显式。
这一建筑选择强制执行局部推理：包含 try 的代码行立即向读者发出信号，表示执行可能无法继续到下一条语句。与Objective-C的 @try/@catch 块在没有错误发生时仍会产生运行时开销不同，Swift的方法使用零成本抽象，只有在实际抛出错误时才会优化错误传播。因此，try 关键字既充当了视觉安全标记，又作为编译指令，确保通过类型系统做到全面的错误处理。
在设计医疗记录管道时，我们的团队需要对三项容易失败的操作进行顺序处理：解析 JSON 元数据、验证 X.509 数字签名以及使用 AES-256 解密患者数据。每个阶段产生不同的错误类别——语法错误、过期的证书或无效的密钥——我们需要对具体的失败阶段进行详细的遥测，以便满足HIPAA审计日志的要求。
我们最初的方法依赖于使用 guard let 语句的 Optional 返回类型，其中 parseMetadata() -> Metadata? 在任何失败时返回 nil。这在调试中证明是灾难性的，因为生产日志只显示解密失败，而无法表明是由于输入损坏还是签名不匹配导致失败。嵌套的 guard 语句导致的“绝望金字塔”还模糊了线性数据流，使重构容易出错。
随后我们尝试了显式的 Result<Metadata, ParseError> 返回。尽管这保留了错误上下文，但模板代码变得压倒性。组合操作需要冗长的 switch 语句或 flatMap 链，使代码维护变得比我们从 Objective-C 迁移过来的错误指针模式更困难。手动在管道中传递结果的认知负担超过了安全好处。
最终，我们采用了抛出函数以及符合 Error 协议的自定义 MedicalRecordError 枚举。通过将每个阶段标记为 throws，我们利用 try 关键字在安全审计期间使失败点可见，同时允许错误传播到一个集中的 do-catch 块。这个解决方案的选择因为它在类型安全和可读性之间取得了平衡；显式的 try 注解作为可能终止正常路径的操作的强制性文档。我们将错误处理代码量减少了45%，并且在没有手动错误累积逻辑的情况下实现了完整的审计跟踪。
enum MedicalRecordError: Error { case invalidJSON case signatureExpired case decryptionFailed } func processPatientRecord(_ input: Data) throws -> PatientRecord { let metadata = try parseMetadata(input) // 显式失败点 try validateSignature(metadata, input) // 安全关键的可见性 return try decrypt(input, key: metadata.key) }
try? 和 try! 之间的语义差异是什么，为什么 try? 会静音错误而不是处理它们？
候选人经常将 try? 與可选链混淆，假设它提供了一种安全地忽略错误的方法。实际上，try? 立即将任何抛出的错误转换为 nil，丢失所有诊断信息并阻止任何恢复逻辑的执行。这与 try! 有本质区别，后者断言错误是不可能的，并在这个假设被违反时触发运行时陷阱（进程终止）。初学者应该理解，try? 仅在特定错误类型无关且操作确实是可选时是合适的，而 try! 表示程序中的逻辑错误，这种错误不应被发布到生产环境中。
rethrows 关键字如何影响高阶函数的 ABI 和调用约定，当传递一个不抛出闭包时为何可以在没有 try 的情况下调用 rethrows 函数？
许多候选人将 rethrows 看作仅仅是文档，但它实际上在 ABI 级别上建立了条件函数签名。当一个函数被标记为 rethrows 时，编译器生成两个入口点：一个用于抛出情况，另一个为非抛出情况进行优化。如果闭包参数在编译时被证明是非抛出，则调用者调用优化路径并省略 try 关键词，因为该函数的类型系统契约确保不会有错误溢出。这种双 ABI 方法允许在保持高阶转换灵活性的同时为 map/filter 操作提供零成本抽象。
在抛出错误时，defer 块为何在堆栈展开期间执行，以及这种交互如何与 catch 块中的显式清理相比保证资源安全？
候选人经常认为 defer 仅在正常作用域退出时执行，或假设抛出的错误会绕过 defer 语句。在 Swift 中，defer 块在范围退出时始终以 LIFO 顺序执行，包括在错误传播的堆栈展开期间。这种建筑保证确保在 defer 注册和随后的 throw 之间获取的资源总是释放，即使错误发生在深层嵌套的条件分支中。与在多个 catch 块中重复的手动清理——在重构中有遗漏的风险不同——紧接在资源获取之后放置的 defer 保持了通过单个、本地化声明的安全不变性。