8

我阅读了 Apple 关于异常使用和NSError使用的建议：

另外，我阅读了几个类似的堆栈溢出问题，讨论是否使用异常。

iOS 中的异常处理

在 Objective-C 中使用异常

Objective-C 异常

我试图找出使用异常作为 iOS 中错误通知/处理方法的利弊（坦率地说，我对 Apple 的句子不满意（它说明了要做什么，但没有说明我们为什么要这样做）：

您应该将异常用于编程或意外的运行时错误，例如越界集合访问、尝试改变不可变对象、发送无效消息以及失去与窗口服务器的连接。您通常在创建应用程序时而不是在运行时处理这些类型的异常错误。

异常使用优点：

  • 不需要修改错误生成代码和错误处理代码之间的所有中间代码

  • 它不会污染方法的参数和返回值

缺点：

  • 对于所有手动管理的内存代码，我们必须格外小心（我们需要将其包装在自动释放对象中以确保资源被释放）。

  • 我们需要小心我们的代码和框架之间的边界。如果我们的异常离开我们的代码，我们可能会遇到麻烦（因为框架可能会手动管理内存）

我错过了什么吗？还有其他的缺点/优点吗？

看起来异常对于像代码这样的库应该没问题（当我们有大量紧密打包的代码时，它们与外部系统/框架的通信不多。而且看起来异常很难用于积极的代码与其他框架交互。

你的经验能证明这个理论吗？

我感谢有关此主题的任何其他信息。

4

1 回答 1

13

tl;dr 异常应仅用于致命/不可恢复/程序员错误。尝试在 Java 或其他可恢复异常的环境中使用它们会导致代码更脆弱、更难维护和难以重构，同时还会限制您利用系统框架的能力。

缺点：如果您在代码中使用异常来控制流程和/或可恢复错误，那么您的代码在设计上将与 Apple 的设计模式不同。

最终结果？

• 你不能在你的代码中使用 Apple 的 API ，除非你的代码和 Apple 之间的边界总是隔离异常行为

• 每次重构时，都必须重构大量异常处理代码

• 许多本应微不足道的事情将变得非常复杂。例如，您将无法将您的对象放入可枚举的集合中并在没有该枚举的情况下枚举它们——块、for循环等……——在边界处也有异常处理。

考虑：

 NSArray *a = @[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance];

@try {
    for(id k in a) { [k doSomething]; }
} @catch(...) {
}

如果出于任何原因可能会引发上述情况，则违反了框架的记录设计模式，因为您将在 Apple 框架内的框架之间doSomething引发异常。

这是一个巨大的骗局。大到我无法想象有一组专业人士能胜过它。

于 2012-10-02T18:10:02.047 回答