我阅读了Apple关于exception用法和NSError用法的建议：
另外，我读了几个类似的堆栈溢出问题，讨论是否使用异常。
Using exceptions in Objective-C
我试图找出使用异常的优缺点作为iOS中的错误通知/处理方法（坦率地说，我对Apple的句子不满意（它说要做什么，但它没有说明为什么我们应该这样做它）：
您应该保留使用例外编程或 意外的运行时错误，例如越界集合访问， 试图改变不可变对象，发送无效消息，以及 失去与窗口服务器的连接。你经常照顾 当应用程序存在时，这些类型的错误和异常 创建而不是在运行时。
异常使用专业人员：
不需要修改错误生成代码和错误处理代码之间的所有中间代码
它不会污染参数并返回方法
缺点：
对于所有手动管理的内存代码，我们必须格外小心（我们需要将其包装在自动释放对象中，以确保释放资源）。
我们需要注意代码和框架之间的边界。如果我们的例外留下我们的代码，我们可能会遇到麻烦（因为框架可能会手动管理内存）
我错过了什么吗？还有其他缺点/专业人士吗？
看起来异常应该适用于类似代码的库（当我们有大量紧密封装的代码时，它们与外部系统/框架没有很多通信。而且看起来异常很难用于与其他框架积极互动的代码。
您的经验证明了这一理论吗？
我感谢有关此主题的任何其他信息。
答案 0 :(得分：13)
tl; dr异常应仅用于致命/不可恢复/程序员错误。尝试在Java或其他异常可恢复的环境中使用它们将导致代码更脆弱，更难维护，难以重构，同时也限制了您利用系统框架的能力。
Con：如果您在代码中使用流控制和/或可恢复错误的异常，那么您的代码将与Apple的设计模式不同。
最终结果？
•除非代码与Apple的之间的边界始终隔离异常行为，否则您无法在代码中使用Apple的
•每次重构时，您都必须重构大量的异常处理代码
•许多应该是微不足道的事情将非常复杂;例如，你将无法将你的对象放入一个可枚举的集合中，并且在没有枚举的情况下枚举它们 - block，for循环，等等...... - 在边界处也有异常处理。
考虑：
NSArray *a = @[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance];
@try {
for(id k in a) { [k doSomething]; }
} @catch(...) {
}
如果doSomething可能由于任何原因而引发上述内容违反了框架的文档设计模式，因为您将在Apple框架内的框架中抛出异常 ）。
这是一个强大的骗局。足够大，我无法想象一组专业人士会超过它。