iPhone 生产/发布异常处理答案

【问题标题】：iPhone Production/Release Exception HandlingiPhone 生产/发布异常处理
【发布时间】：2011-03-06 23:30:42
【问题描述】：

请原谅我对 iPhone/Objective-C 最佳实践缺乏了解；我来自 .NET/C# 背景。

尽管我已经阅读了很多关于 iPhone 异常处理的帖子，但我仍然不清楚大多数人为生产代码所做的工作。此外，我还没有找到任何具有我通常期望的错误处理的开源应用程序。以下是我的问题：

1) 如果出现意外的结果导致应用程序最终失败，你会抛出异常还是等待它稍后失败？例如，

if (![fileManager createDirectoryAtPath: myNewDir
    withIntermediateDirectories: YES 
    attributes: nil 
    error: &myError]) {

    // My app shouldn't continue. Should I raise an exception? 
    // Or should I just log it and then wait for it to crash later?
}

2) 你验证参数吗？例如，在 C# 中，我通常会检查 null，如果需要，会抛出 ArgumentNullException。

3) 当应用程序崩溃时，崩溃信息会自动记录，还是我需要设置未处理的异常处理程序？我可以在这个方法中显示一个 UIAlertView 来通知用户发生了一些不好的事情，而不是让应用程序消失吗？（如果是这样，我无法让它工作。）

4) 最后，为什么我没有看到有人实际使用@try/@catch/@finally？它在 C# 中被广泛使用，但我还没有找到使用它的开源应用程序。（也许我只是在查看错误的应用程序。）

【问题讨论】：

标签： iphone objective-c exception-handling production-environment

【解决方案1】：

广告 1. 您给出的示例是一个有点经典的示例，说明何时应该在 Java 中使用“已检查异常”。方法的调用者必须做好准备，调用可能会由于超出其无法控制的原因而失败。特别是，在给出的示例中，我将允许错误描述符对象传播回调用者：

- (BOOL) prepareDirectories: (NSString*) path error: (NSError**) location {

    if( ![fileManager createDirectoryAtPath: path
                      withIntermediateDirectories: YES 
                      attributes: nil 
                      error: location] ) {

        return NO;
    }

    // ... additional set-up here
    return YES;
}

如果错误确实不可恢复，您实际上可能会引发异常，但这也将失去向应用程序用户显示正确错误消息的任何机会。

广告 2. 是的，参数验证绝对是您应该做的事情。并且为意外的nils 提出例外是完全合适的。错误的参数是“程序员的错误”，您不能保证程序仍处于一致状态。例如，NSArray 会引发异常，如果您尝试使用不存在的索引获取元素。

广告 3. 当应用程序由于未捕获的异常而崩溃时，会自动记录该事实。如果您真的想显示错误消息，您可以捕获异常。但是，应用程序可能处于不一致的状态，不应允许继续运行，因此简单地让它停止似乎是最好的解决方案。

广告 4。我不知道。

【讨论】：

【解决方案2】：

在您提到的特定情况下，您应该向用户提供有关刚刚发生的事情的通知，并提供有关如何解决该情况的说明。除非在极端情况下，您的应用不应退出。您应该让用户修复任何错误，然后重试。
参数验证取决于很多因素。要记住的一件事是，在 Obj-C 中，向nil 发送消息是完全有效的（如果你这样做，则不会发生任何事情），因此在很多情况下你不需要检查 nil。如果我在模型类中，我总是验证方法中的参数。如果我不是，我几乎从不验证任何东西，类型检查就足够了。
应该记录一些信息，但记录更具体的信息对于您的情况总是有帮助的。理想情况下，您永远不应该达到未处理的异常状态。
Cocoa 类很少会因为环境原因抛出异常，它们几乎总是因为你做错了什么。例如，您通常不会在[NSString stringWithString:] 周围放置@try/@catch 块，因为它引发异常的唯一方法是您尝试传递nil。确保您没有通过nil，并且您不必担心捕获异常。当一个方法可能因为你无法控制的事情而失败时，它们通常通过 NSError 进行通信。以NSManagedObjectContext 的- (BOOL)save:(NSError **)error 方法为例。

【讨论】：