软件|如何优雅做系统错误提示？软件

\">我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我哟～
每周五12点按时送达～
我的第「149」篇原创敬上

大家好，我是Z哥。
不管是日常的工作中还是生活中，我们每天会用到很多软件系统。
不知道你有没有过这样的感受，当你使用软件遇到异常的时候，有时候软件给出的错误提示让人摸不着头脑。唯一的办法就是复制到搜索引擎搜一下，看看有没有哪个不幸的人与我遇到一样的问题。
所以，一个好的错误提示特别重要。它不但能让使用者明白当前到底发生了什么，甚至还能引导如何解决异常。达到这个程度的话自然可以大大提高系统的使用效率，也能间接降低己方商务人员或者产品经理的培训成本。
因此，作为程序员群体的一份子，在这里我想呼吁大家认真对待错误提示，特别是那些不是给“人”看的错误提示……
作为软件的创造者，我们虽然无法避免出现异常、出现bug ，但是我们可以做到避免无意义的错误提示产生。
首先，一些常见的容易让人摸不着头脑的错误提示要先避免。比如，

提交失败。
数据读取失败。
……

这类错误提示看上去准确表达了当前遇到的问题，实际上啥也没说。你想象一下，当我点击一个提交按钮之后，页面没有跳转而且还弹个框出来，哪怕里面什么字都没写，我能也猜到这里估计出错了。
但是具体错在哪？作为用户该如何处理？一概不知。
另外，还有一种常见的情况是，错误提示含有太多的技术术语，使用者根本不明白啥意思，也不关心这些。比如，

远程服务响应超时。
事务执行失败， XX保存失败。
……

其实这还算好的，有的甚至把技术框架中返回的expcetion信息直接作为错误提示出来。这对用户看起来就是一堆乱码，他只会找你说“系统乱码了，帮我解决一下……” 。
如果上面的景象就在你日常工作中发生，也不用不好意思，我们都是这么过来的。 Z哥我自己以前也同样没意识到这个问题，经过了这些年的工作之后，我认为，编写正确的错误提示可以按照以下的思路来。
/01 不要提示用户不关心的信息/首先来个排除法。
我们作为程序员经常需要通过一些技术性的线索来排查问题，特别是expcetion信息。但用户并不关心它们，而且他们无法对此类消息进行任何处理。
所以，这些信息记录到日志里就好，页面上无需给出这种用户不关心的信息。
/02 清楚表达问题原因/让用户清楚的知道问题的原因，是他能否自行解决问题的基础。
比如，前面提到的“提单失败”的例子，你告诉他由于缺少XX信息导致提交失败，那么使用者自然会去想办法把缺少的信息给补上。
我还记得我之前用某个邮箱的时候，有封邮件发不出去，它总是提示我“邮件发送失败。 ”我真是服了，到底啥原因发送失败，后来经过自己不断的测试才知道是某个附件太大了导致发送失败。
/03 给出引导建议/这点在一些企业内部使用的系统，以及一些toB的项目中特别重要。因为大多数系统使用者都只负责自己工作相关的部分，对其他的模块并不了解。所以，哪怕你将问题的原因表达的很清楚，但是他还是不知道该如何解决，只能寻求产品经理或者开发人员的协助。
比如，电商平台的客服在后台替用户修改订单收货地址的时候，发现某个地区下没有可用快递可选。如果你没有给出引导，诸如“联系XX人员进行设置。 ”之类的内容，那么他们只能来找你解决，无其他路可走。
如果想做得更好一些，针对某些场景可以直接放出下一步操作的连接，这样用户可以直接到达需要他进行操作的页面。
/04 提示内容尽可能简短/文字一多，大多数人都不会逐字逐句看的，甚至有些人会完全不看。
Z哥工作中遇到过无数次这种情况。不管是错误提示还是操作提示，不管你写的多么详细、清楚，只要文字超过2行或者有几十个字以上，很多人看都不看直接截个图发给你，问你该怎么办？
听说有个美国机构做过相关的研究：

如果句子中的单词数不超过8个，读者可以理解其中的100％。
如果句子包含43个单词或更长的单词，则读者的理解力将下降到不足10％。

虽然这个研究说的是英文，但是中文也是类似的道理。不过我没找到这个研究的具体出处，不知道真假，但是我觉得这个结论还是很符合常识的。
以上这4点说起来简单，也很好理解，没什么新奇的。但是真正做的时候很多人就把它们抛之脑后了。
当然，比给出合理的错误提示更好的是，避免出现错误。所以你还可以更进一步，提前规避掉一些错误。
比如，