第七章_敏捷调试_37 提供有用的错误信息

37 提供有用的错误信息

1. 问题是什么？

本章节中描述的内容是什么呢？

夫子曰：继 36 报告所有的异常 之后，如何报告异常，报告异常时，要提供些什么信息呢？本问着眼点即在于此，同时，报告异常时，也要根据发生异常的用户，报告不同的内容。

如用户操作触发的异常，报告些什么呢？软件程序本身执行的异常，应该向开发人员报告些什么呢？软件运行环境触发的异常，向运维人员，或者开发人员报告些什么呢？

2. 恶魔的方案

不要吓着用户，吓程序员也不行。要提供给他们干净整洁的错误信息。要使用如下这样让人舒服的词句：‘用户错误，替换，然后继续’“

3. 天使的方案

重现问题

错误报告对于开发人员的生产率，以及最终的支持活动消耗成本，都有很大的影响。

在开发过程中，如果定位和修复问题让人倍受挫折，就考虑适用更加积极主动地错误报告方式吧。

调试信息非常宝贵，而且不宜获得，不要轻易将其丢弃。

展示有用的错误信息

提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。

区分错误类型

• 程序缺陷

代码本身的问题

• 环境问题

代码产品运行环境的问题

• 用户错误

用户适用软件产品过程中出现的错误，经指导后，用户可以解决。

4. 天使不在的时候，怎么办？

• “无法找到文件”这样子的错误信息，是无法帮助解决问题的。“无法打开/andy/project/man.yaml以供读取“这样的信息更有效
• 在提供更多信息的同事，不要泄露敏感信息
• 提供给用户的信息中可以包含一个关键信息，方便其在今后日志文件中定位与问题相关的信息。

5. 切身感受

错误信息有助于问题的解决。当问题发生时，可以详细研究问题的细节描述和上下文环境。

6. 总结

问题发生后，报告异常的内容，也是一个极需要设计的主题。

不能多，也不能少。

根据异常处理对象的不同，报告内容也不同，可以提供帮助其解决问题，或者异常的信息，才是一个良好的设计。

这才是敏捷调试的必备活动之一。