提供有用的错误信息
——
高效程序员的
45
个习惯之习惯37
“不要吓着用户,吓程序员也不行。要提供给他们干净整洁的错误信息。要使用类似‘用户错误。替换,然后继续。’这样让人舒服的词句。”
当应用发布并且在真实世界中得到使用之后,仍然会发生这样那样的问题。比如计算模块可能出错,与数据库服务器之间的连接也可能丢失。当无法满足用户需求时,要以优雅的方式进行处理。
类似的错误发生时,是不是只要弹出一条优雅且带有歉意的信息给用户就足够了?并不尽然。当然了,显示通用的信息,告诉用户发生了问题,要好过由于系统崩溃造成应用执行错误的动作,或者直接关闭(用户会因此感到困惑,并希望知道问题所在)。然而,类似“出错了”这样的消息,无法帮助团队针对问题做出诊断。用户在给支持团队打电话报告问题时,我们希望他们提供足够多且好的信息,以帮助尽快识别问题所在。遗憾的是,用很通用的错误消息,是无法提供足够的数据的。
针对这个问题,常用的解决方案是记录日志:当发生问题时,让应用详细记录错误的相关数据。错误日志最起码应该以文本文件的形式维护。不过也许可以发布到一个系统级别的事件日志中。可以使用工具来浏览日志,产生所有日志信息的
RSS feed
,以及诸如此类的辅助方式。
记录日志很有用,可是单单这样做是不够的:开发人员认真分析日志,可以得到需要的数据;但对于不幸的用户来说,起不到任何帮助作用。如果展示给他们类似下图
中的信息,他们还是一点头绪都没有
——
不知道自己到底做错了什么,应该怎么做可以绕过这个错误,或者在给技术支持打电话时,应该报告什么。
如果你注意的话,在开发阶段就能发现这个问题的早期警告。作为开发人员,经常要将自己假定为用户来测试新功能。要是错误信息很难理解,或者无助于定位错误的话,就可以想想真正的用户和支持团队,遇到这个问题时会有多么困难了(见图
7-2
)。
图
7-2
无用的异常信息
例如,假定登录
UI
调用了应用的中间层,后台向数据访问层发送了一个请求。由于无法连接数据库,数据访问层抛出一个异常。这个异常被中间层用自己的异常包裹起来,并继续向上传递。那么
UI
层应该怎么做呢?它至少应该让用户知道发生了系统错误,而不是由用户的输入引起的。
接下来,用户会打电话并且告诉我们他无法登录。我们怎么知道问题的实质是什么呢?日志文件可能有上百个条目,要找到相关的细节非常困难。
实际上,不妨在显示给用户的信息中提供更多细节。好比说,可以看到是哪条
SQL
查询或存储过程发生了错误;这样可以很快找到问题并且修正,而不是浪费大把的时间去盲目地碰运气。不过另一方面,在生产系统中,向用户显示数据连接问题的特定信息,不会对他们有多大帮助。而且有可能吓他们一跳。
一方面要提供给用户清晰、易于理解的问题描述和解释,使他们有可能寻求变通之法。另一方面,还要提供具备关于错误的详细技术细节给用户,这样方便开发人员寻找代码中真正的问题所在。
下面是一种同时实现上述两个目的方式:图
中显示了清晰的错误说明信息。该错误信息不只是简单的文本,还包括了一个超链接。用户、开发人员、测试人员都可以由此链接得到更多信息,如图
7-
3
、图
7-4
所示。
图
7-3
带有更多细节链接的异常信息
图
7-4
供调试用的完整详细信息
进入链接的页面,可以看到异常(以及所有嵌套异常)的详细信息。在开发时,我们可能希望只要看到这些细节就好了。不过,当应用进入生产系统后,就不能把这些底层细节直接暴露给用户了,而要提供链接,或是某些访问错误日志的入口。支持团队可以请用户点击错误信息,并读出错误日志入口的相关信息,这样支持团队可以很快找到错误日志中的特定细节。对于独立系统来说,点击链接,有可能会将错误信息通过电子邮件发送到支持部门。
除了包括出现问题的详细数据外,日志中记录的信息可能还有当时系统状态的一个快照(例如
Web
应用的会话状态)。
使用上述信息,系统支持团队可以重建发生问题的系统状态,这样对查找和修复问题非常有效。
错误报告对于开发人员的生产率,以及最终的支持活动消耗成本,都有很大的影响。在开发过程中,如果定位和修复问题让人倍受挫折,就考虑使用更加积极主动的错误报告方式吧。调试信息非常宝贵,而且不易获得。不要轻易将其丢弃。
展示有用的错误信息
提供更易于查找错误细节的方式。发生问题时,要展示出尽量多的支持细节,不过别让用户陷入其中。
区分错误类型
程序缺陷。
这些是真正的 bug ,比如 NullPointerException 、缺少主键等。用户或者系统管理员对此束手无策。
环境问题。 该类别包括数据库连接失败,或是无法连接远程 Web Services 、磁盘空间满、权限不足,以及类似的问题。程序员对此没有应对之策,但是用户也许可以找到变通的方法,如果提供足够详细的信息,系统管理员应该可以解决这些问题。
用户错误。 程序员与系统管理员不必担心这些问题。在告知是哪里操作的问题后,用户可以重新来过。
通过追踪记录报告的错误类型,可以为受众提供更加合适的建议。
切身感受
错误信息有助于问题的解决。当问题发生时,可以详细研究问题的细节描述和发生上下文。
平衡的艺术
-
像“无法找到文件”这样的错误信息,就其本身而言无助于问题的解决。“无法打开
/andy/project/main.yaml
以供读取”这样的信息更有效。
-
没有必要等待抛出异常来发现问题。在代码关键点使用断言以保证一切正常。当断言失败时,要提供与异常报告同样详细的信息。
-
在提供更多信息的同时,不要泄露安全信息、个人隐私、商业机密,或其他敏感信息(对于基于
Web
的应用,这一点尤其重要)。
-
提供给用户的信息可以包含一个主键,以便于在日志文件或是审核记录中定位相关内容。
- 大小: 18 KB
- 大小: 34.2 KB
- 大小: 19.3 KB
分享到:
相关推荐
优秀程序员的十个习惯
优秀程序员需要具备的习惯,如果能够达到以上要求,it界必然有你一席之地。
[12]优秀程序员之路——C++开发经验及技巧大汇总.zip上位机开发VC串口学习资料源码下载[12]优秀程序员之路——C++开发经验及技巧大汇总.zip上位机开发VC串口学习资料源码下载[12]优秀程序员之路——C++开发经验及...
高级程序员的45个好习惯,很多很经典的习惯有助于你的开发之路
37. 提供有用的错误信息 第8章 敏捷协作 38. 定期安排会面时间 39. 架构师必须写代码 40. 实行代码集体所有制 41. 成为指导者 42. 允许大家自己想办法 43. 准备好后再共享代码 44. 做代码复查 45. 及时通报进展与...
王牌9 优秀程序员之路——Java开发经验及技巧大汇总
word文档关于程序员的习惯 如何成为优秀程序员的方法
王牌9_优秀程序员之路——C++开发经验及技巧大汇总
优秀程序员的45个习惯.rar ok good
优秀程序员之路——ASP.NET开发经验及技巧大汇总
优秀程序员之路——Java开发经验及技巧大汇总.zip
优秀程序员的45个好习惯,看看总有好处的
黑马程序员——Android移动开发源码
C#从入门到精通的王牌九: 优秀程序员之路——C# 开发经验及技巧大汇总
程序员——必看的文档 程序员——必看的文档 程序员——必看的文档 程序员——必看的文档
好的代码风格对于优秀的程序员是必须的。 免费共享 程序员之路——关于代码风格。
自己总结的《高效程序员的45个习惯》,把书中自己感觉较好的段落摘抄下来,稍稍加了点自己的想法,挺好的...
程序员晋升.doc————电子版_doc版
王牌10 优秀程序员之路——C开发经验及技巧大汇总.pdf 这本书还是不错的。有兴趣的朋友可以看看。
-【SAP- 程序员培训—ABAP4程序员之路——第2天】(PPT 22板.ppt