怎样做错误处理

生活中的告示，路障，路标都是错误处理的手段

首先请思考一个貌似浅显的问题：什么样的对用户的影响是最差的？

你可能会想到，页面显示异常或者应用崩溃。
但是实际生活中还有更糟糕的。
比如说数据丢失，手机软件导致手机打电话功能无法正常使用，用户隐私的泄露。恐怕这些都要比应用崩溃来的严重。

我们做错误处理的目的，不外乎让用户能够正常使用，甚至是能够顺畅的使用我们的应用。

原则一：减少对用户对影响

通俗的说就是：大事化小，小事化了。

1. 困惑
   经过思考能够找到正确的使用方法
   需要不断尝试才能找到正确使用的方法
   需要应用外的帮助才能找到正确的使用方法
2. 无法使用
   本次操作失败，重试可以成功
   采取一些措施后才可以正常使用
   完全无法使用
3. 造成损失
   损失严重程度是一个主观的东西，需要看具体损失的类型。
   浪费时间（时长），
   经济损失（价格），
   名誉损失（范围和时间），
   丢失数据（数据重要程度）

我们要做的是，尽量把第3类影响（造成损失）降低到第2类甚至第1类影响。

良好对错误处理可以，让用户使用流畅，没有迷惑。

讳疾忌医的典故《扁鹊见蔡桓公》

讳疾忌医的典故《扁鹊见蔡桓公》，大家应该都比较熟悉了。
随着问题不断遗留到下一个阶段，治疗的成本也在不断的增加。
腠理->肌肤->肠胃->骨髓->GameOver
汤熨->针石->火齐->等死->埋了
为了避免项目进入无药可救的地步，尽早暴露问题才是王道。

原则二：尽早暴露问题

暴露问题的目的是解决问题。尽早的暴露问题，往往更容易解决。
这里的早有两个方面

一个是代码执行流程中尽量早。

举个例子：

假设我们应用中发现界面上的元素显示的有问题。
追根溯源发现，这个元素是服务器端返回的数据刷新出来的。
而数据错是因为客户端请求时传递了错误的参数。
而这个参数传错是因为一个工具类做类型强转时有了精度损失。

基础类库->参数传递->接口请求->接口返回数据->界面显示

这样一个长长的追踪路径，很浪费时间不说，极有可能在某个环节上断掉了线索，从而无法找到原因。

另外一个是暴露问题的开发阶段尽量早。

需求->分析->设计->开发->测试->发布

下一个环节解决问题的成本往往是上一个环节的数倍。
因此能够尽量早的暴露问题就能事半功倍。

合格的程序员按照测试反馈和用户反馈修改BUG。
优秀的程序员编写单元测试、提测前自测。
顶级程序员挑战产品经理完善需求。