带有全局处理程序的 iOS NSError答案

【问题标题】：iOS NSError with global handler带有全局处理程序的 iOS NSError
【发布时间】：2014-10-17 11:28:07
【问题描述】：

我正在开始编写 iOS 应用程序。在阅读了有关如何处理错误的 Apple 指南后，我得到了以下最重要的几点：

现在，NSError 通常作为输出参数传递，然后可以在内部使用，并且必须由调用者检查。但是，我在问自己，使用全局错误处理程序是否是个好主意，比如一个环绕 NSError 的单例，可用于从被调用函数中触发错误和错误处理。

有什么反对这种方法的吗？或者这是一种不好的做法？

【问题讨论】：

我从未见过你所说的指南，但我猜它是从 API 程序员的角度讲的——他会在内部处理异常（如果它们被处理的话）并使用 NSErrors，而不是异常，向 API 调用者报告问题。
我指的指南是Dealing with Errors

【解决方案1】：

MacOS X 具有error responder chain 的概念，它是一种非正式协议，可将错误沿响应者链传播，直到它们得到处理。无论出于何种原因，这在 iOS 上的 Cocoa 中都没有实现，但存在几个第三方实现：

还有更多。

这种方法非常灵活，有据可查，是 MacOS X 上的最佳实践，通常比使用单例更可取。

【讨论】：

【解决方案2】：

这将是一件糟糕的事情，因为您的观点“NSError 是针对用户的”根本不正确。 NSErrors 通知您的软件无法执行操作的原因。这是否是需要告知用户的错误完全取决于具体情况。

【讨论】：

来自文档：“Cocoa 程序使用 NSError 对象来传达有关用户需要了解的运行时错误的信息。” NSError 封装了要呈现给用户的错误信息。这就是为什么它具有本地化、错误原因和描述以及恢复选项的原因。 NSErrors 绝对是供用户使用的。
@quellish - 对大多数用户而言，NSError 中的文本纯属胡言乱语。它们的实际目的是记录下来以帮助诊断错误。
@HotLicks IMO 很明显不向用户呈现 NSError 的原始内容。

【解决方案3】：

在实践中，大多数错误都需要在非常狭窄的上下文中处理，并且尝试在 NSError 类周围包装一些东西不会有任何收获。只需处理错误，然后继续执行。

【讨论】：

【解决方案4】：

iOS 中的大多数异常本质上是“致命的”并且无法有效处理（因此在 iOS 应用程序中使用异常处理程序是不常见的）。

按照惯例，非致命错误通过返回代码或从被调用函数返回零或零来报告。在许多情况下，error: 参数可用，当收到错误的返回码时，应该使用该参数（记录/转储结果 NSError 值）。

（请注意，error: parm 结果不是您检查是否发生错误的结果。相反，其他地方的错误返回代码表示应该记录/转储error: parm 结果。）

很少有向用户报告 NSError 内容有意义的情况——大部分信息只对程序员有意义。

【讨论】：