你应该经常使用try / catch / finally块吗？

Question

作为具有java背景的开发人员，我习惯于经常捕获异常以防止它们崩溃我的应用程序。这包括各种委托方法。只是针对意外情况的额外安全措施。

我的问题是这种方法在目标c中是否合理，是否会引入某种性能问题？换句话说，如果我经常使用try / catch块，我的应用程序会受到什么影响？

Answer 1

它不会遭受那么多苦，但你必须记住一些事情。与您可能拥有ConnectionRefusedException或FileNonexistantException的其他语言不同，在objective-c中，例外情况是90％的程序员错误。因此，当您的应用程序进入生产时，它不应该有任何例外。而不是，例如，捕获超出范围的异常，只需在尝试之前查看数组长度。您可以进行顶级try-catch，以防万一出现错误并且比崩溃更优雅地退出。

Answer 2

通常，您不希望在程序运行时发生异常。因此，在错误发生之前测试错误而不是在错误发生之后捕获它们被认为是更好的编程实践。

最好在方法中测试错误并将某些值作为错误指示符返回，而不是抛出异常。抛出异常会占用大量系统资源，因此，

Apple一般建议不要使用他们不必要的用途（例如，您不想因为无法打开文件而抛出异常）。

Answer 3

最佳做法是，只有在加载由于用户环境设置或用户提交的数据而可能无法正常工作的数据，模块，文件和内容时才使用try和catch。

Answer 4

异常是异常，并且不应经常发生：）），因此它根本不会影响性能。

通常协议包含正常行为和错误的委托方法[例如didLoadResponse: theResponse，didFailWithError: theError]，所有情况都将被涵盖。

我会保留异常，例如写入磁盘时出错，或者远程服务器出现故障 - 实际情况会破坏应用程序。

Answer 5

你会遇到性能问题。如果抛出异常，那么在调试程序时就没问题。但是当应用程序在那里运行时你可能不希望发生这种情况。
我的建议是仅将异常用于调试，然后在发布时禁用它们，并使用更合适的应用程序，如NSError。
假设用户键入一个URL并且此URL无效。您必须加载一个网页。在调试期间您可能只是抛出异常，但是当您拥有该版本时，您可以忽略错误的URL，而不是显示页面，或运行NSAlertPanel以显示错误。

Answer 6

仅将tty / catch用于例外，而不是替换if / then.Overhead非常昂贵。

Answer 7

我刚刚在iPad上进行了一些测试。除非实际抛出异常，否则@ try / @ catch块似乎会引入很少的性能损失。但如果抛出异常，则罚款很大。您没有说明您正在使用的环境。所以你的milage可能会有所不同。