【问题标题】:When to present NSError什么时候出现 NSError
【发布时间】:2013-05-01 14:05:08
【问题描述】:

我有一个普遍的问题——处理 NSError 的一些准则是什么?例如,NSJSONSerialization 在创建 JSON 对象或 JSON 数据时会返回错误。

我觉得在这种情况下(可能)不适合提醒用户?但是错误信息仍然很重要。

所以我不确定何时何地是处理晦涩的、与用户无关的错误的最佳地点?

【问题讨论】:

  • 可以弹出UIAlertView说“与web服务通信失败,请联系开发者”什么的。
  • 内部抛出的错误应该在内部处理。您的用户不知道您的应用程序为什么会抛出错误,为什么您决定向他们显示错误或如何解决它,因此您永远不应该向他们显示错误。如果您无法处理错误(例如致命异常),则“优雅地”崩溃。只是不要因为您应该自己解决的问题而打扰任何人,但因为您的应用测试不足而无法解决。
  • 我认为弹出一个数字或错误字符串并要求将其报告给开发人员并没有什么坏处。不过,您不应该期望/要求报告它。如果您的应用程序可能被用户认为很重要,您应该做的是使用可用的报告机制之一,例如 Flurry 向您自己报告错误(以及您可以收集的任何其他信息)。

标签: ios objective-c json cocoa-touch nserror


【解决方案1】:

这完全取决于引发错误的上下文。

Apple Documentation:

尽可能恢复或向用户显示错误

最好的用户体验是让您的应用透明地从 一个错误。例如,如果您正在发出远程 Web 请求,您 可能会尝试使用不同的服务器再次发出请求。 或者,您可能需要向 尝试之前的用户,例如有效的用户名或密码凭据 再次。

因此,在某些情况下,您可能希望用户隐藏错误,并可能退回到错误恢复路径

在某些情况下,您希望让用户知道发生的错误并采取纠正措施。

同时,在许多情况下,作为程序员,我们希望在控制台上记录错误,以便我们可以在测试时修复它们。

附带说明一下,在很多情况下,我们会抛出自定义 NSError 对象并通过警报、日志记录或其他方式处理它们!

我相信,值得通过共享的 Apple 文档链接!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-01-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-10-16
    • 1970-01-01
    • 2016-10-03
    • 2016-02-01
    相关资源
    最近更新 更多