有效的iOS错误管理
曾几何时，王国中有一个很棒的App。 该应用程序非常复杂，并包含许多晦涩难懂的部分，但它给使用它的所有用户带来了极大的欢乐。
但是，有一天，一个邪恶的错误出现了，并向王国的App用户显示了一个难看且难以理解的错误代码。
一位勇敢的开发人员被要求杀死龙来修复该错误，并且得到的票差不多是这样的：
“用户无法继续购买-有时会出现一个奇怪的错误，有时什么也没有发生。”
勇敢的开发者拿起他的键盘，然后…忽略了该错误，删除了整个代码库，并重新编写了Swift 5中的所有内容。
再也没有看到错误代码，从此以后他们都过着幸福的生活。
结束。
不幸的是，现实生活中没有这样的童话。 存在错误，作为开发人员，您的任务是了解问题并加以解决。
现在，让我们看一下最常见的问题和iOS应用程序中通常如何处理错误的不足之处。
当应用失败并没有任何反应时，这可能意味着某个时刻丢失了一个或多个错误。
例如：
虽然这种方法的一些负面结果可能看起来很明显，但其他一些则更加模棱两可。
- 显而易见的是：用户屏幕上出现难看且难以理解的错误消息
这些错误消息显然不是针对用户的。 这些对用户可见的唯一结果是在App Store中有许多不良评论。
- 模棱两可：重要信息的丢失
相同的低级（网络/解析/核心数据）错误可能会以多种不同方式影响您的应用。 如果仅传播原始错误，则介于两者之间的所有信息都将丢失，不被记录或跟踪，最终调试该错误将变得更加困难。
对于用户而言，这些不希望的结果以及代码的完整性可以并且应该避免。
或者，如何以标准且一致的方式传播错误。
错误管理始终是任何应用程序的重要组成部分，甚至更重要的是，如果您的应用程序分为内部Pod，开发Pod，开放源Pod，库，实用程序和内部框架。 在整篇文章中，我们将这些依赖项称为“ 模块 ”。
在Just Eat，我们探索了Swift / Objective-C代码库的几种选择。 最后，我们选择继续使用经典的常绿NSError和NSUnderlyingErrorKey Universe，这是一种特别在macOS中使用的方法，自平台诞生之初就由Apple提出。
在介绍建议的解决方案之前，让我们先介绍几个关键概念。
如官方文档和NSHipster在本文中所述，NSError对象由以下内容组成：
- 错误域 -表示“错误上下文”或错误来源的字符串。
- 错误代码 -表示错误的Int值。 错误创建者有责任使其有意义。 不同的域可以具有完全不同的含义的相同错误代码。
- 用户信息字典 -包含有关错误的所有其他有用信息的字典。
错误链是NSError的链接列表。 每个错误都使用标准键NSUnderlyingErrorKey将先前的错误嵌入到用户信息字典中。 您可以将其视为标准链接列表。 如下所示。
我们汇总了一组准则，以统一我们在所有应用程序的各个部分，模块和库中进行错误管理的方法。
最终结果是一个一致的代码库
- 传播
- 展示架
- 日志
应用中生成的任何错误。
这意味着从应用程序用户界面收到的最终错误结构如下所示：
原始出版物：