iPhone生产/发布异常处理

Question

提前请原谅我对 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# 中被广泛使用，但我还没有找到使用它的开源应用程序。 （也许我只是看错了应用程序。）

Answer 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;
}

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

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

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

广告4。我不知道。

Answer 2

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