如果这个问题已在其他地方得到解答，请道歉，但在搜索时我找不到任何决定性的答案：
我想知道在objective-c iPhone应用程序中使用try-catch块的时间。 Apple的“Objective-C编程语言简介”指出，异常是资源密集型的，并且应该“不使用例外进行一般流控制，或者只是表示错误”。通过阅读这里的一些相关问题，我还得知人们并不经常在实践中使用这种方法。
所以我想问题是：在为iPhone / Objective-C开发时使用try-catch块是否合适，什么时候绝对不能使用？
例如，在处理数组中的对象时，我可以使用它们来捕获超出边界和其他异常。我有一个方法，执行很少的任务与在多个数组中传递的对象。如果发生错误，该方法返回nil，try-catch块可以帮助我捕获异常。但是，我当然可以在这里和那里简单地编写一些if-tests，以确保我，例如，永远不会尝试访问超出数组边界的索引。在这种情况下你会做什么？
非常感谢！
答案 0 :(得分：28)
仅使用@ try / @ catch来处理不可恢复的错误。使用@ throw / @ try / @ catch来执行类似操作的控制流是不合适的。
特别是，除非你的目标是捕获它们并以某种方式报告错误，否则用于捕获越界异常是不合适的 - 然后 - 通常 - 崩溃或至少警告用户您的应用处于不一致状态，可能会丢失数据。
通过系统框架代码抛出的任何异常的行为都是未定义的。
进行边界检查的if-test是一个更合适的解决方案。
答案 1 :(得分：19)
在Cocoa中，通常应避免使用异常（@try/@catch[/@finally]）进行流控制。正如您所提到的，异常带来了非常大的成本（与运行时相比，例如JVM或针对异常使用而优化的CLR）。此外，大多数Cocoa框架都不是例外。因此，通过Cocoa框架代码抛出异常是危险的，并且可能会导致应用程序中出现奇怪，难以诊断和灾难性（认为可能的数据丢失）错误。
Cocoa代码使用NSError来表示应用程序中可恢复的错误情况，而不是使用异常。例外用于表示应用程序无法恢复的条件。因此，在尝试访问给定的越界位置时，可以用错误（向用户呈现其请求无法完成的原因）发信号通知请求模型阵列中的越界位置的UI组件。你认为应该有效的索引表示你的应用程序处于不一致状态并且应该在它可以造成更多伤害之前尽快死亡的异常情况。
NSParameterAssert，例如断言失败时带NSException的信号。
所以当 时，你会使用例外或@try/@catch吗？如果您正在使用一个使用异常的C / C ++库，那么您应该在它们被Cocoa代码抛回之前捕获这些异常。同样，如果您认真对待应用程序中状态的一致性，那么只要您检测到您的状态不一致（并且不可恢复），应该引发异常。