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

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

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

广告3.当应用程序由于未捕获的异常而崩溃时，该事实将自动记录。 如果您确实要显示错误消息，则可以捕获该异常。 但是，该应用程序可能处于不一致状态，因此不应继续运行，因此，仅允许其关闭似乎是此处的最佳解决方案。

广告4.我不知道。

Answer 2

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