这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「149」篇原创敬上
大家好，我是Z哥。
不管是日常的工作中还是生活中，我们每天会用到很多软件系统。
不知道你有没有过这样的感受，当你使用软件遇到异常的时候，有时候软件给出的错误提示让人摸不着头脑。唯一的办法就是复制到搜索引擎搜一下，看看有没有哪个不幸的人与我遇到一样的问题。
所以，一个好的错误提示特别重要。它不但能让使用者明白当前到底发生了什么，甚至还能引导如何解决异常。达到这个程度的话自然可以大大提高系统的使用效率，也能间接降低己方商务人员或者产品经理的培训成本。
因此，作为程序员群体的一份子，在这里我想呼吁大家认真对待错误提示，特别是那些不是给“人”看的错误提示……
作为软件的创造者，我们虽然无法避免出现异常、出现bug，但是我们可以做到避免无意义的错误提示产生。
首先，一些常见的容易让人摸不着头脑的错误提示要先避免。比如，
提交失败。
数据读取失败。
……
这类错误提示看上去准确表达了当前遇到的问题，实际上啥也没说。你想象一下，当我点击一个提交按钮之后，页面没有跳转而且还弹个框出来，哪怕里面什么字都没写，我能也猜到这里估计出错了。
但是具体错在哪？作为用户该如何处理？一概不知。
另外，还有一种常见的情况是，错误提示含有太多的技术术语，使用者根本不明白啥意思，也不关心这些。比如，
远程服务响应超时。
事务执行失败，XX保存失败。
……
其实这还算好的，有的甚至把技术框架中返回的expcetion信息直接作为错误提示出来。这对用户看起来就是一堆乱码，他只会找你说“系统乱码了，帮我解决一下……”。
如果上面的景象就在你日常工作中发生，也不用不好意思，我们都是这么过来的。Z哥我自己以前也同样没意识到这个问题，经过了这些年的工作之后，我认为，编写正确的错误提示可以按照以下的思路来。
/01 不要提示用户不关心的信息/
首先来个排除法。
我们作为程序员经常需要通过一些技术性的线索来排查问题，特别是expcetion信息。但用户并不关心它们，而且他们无法对此类消息进行任何处理。
所以，这些信息记录到日志里就好，页面上无需给出这种用户不关心的信息。
/02 清楚表达问题原因/
让用户清楚的知道问题的原因，是他能否自行解决问题的基础。
比如，前面提到的“提单失败”的例子，你告诉他由于缺少XX信息导致提交失败，那么使用者自然会去想办法把缺少的信息给补上。
我还记得我之前用某个邮箱的时候，有封邮件发不出去，它总是提示我“邮件发送失败。”我真是服了，到底啥原因发送失败，后来经过自己不断的测试才知道是某个附件太大了导致发送失败。
/03 给出引导建议/
这点在一些企业内部使用的系统，以及一些toB的项目中特别重要。因为大多数系统使用者都只负责自己工作相关的部分，对其他的模块并不了解。所以，哪怕你将问题的原因表达的很清楚，但是他还是不知道该如何解决，只能寻求产品经理或者开发人员的协助。
比如，电商平台的客服在后台替用户修改订单收货地址的时候，发现某个地区下没有可用快递可选。如果你没有给出引导，诸如“联系XX人员进行设置。”之类的内容，那么他们只能来找你解决，无其他路可走。
如果想做得更好一些，针对某些场景可以直接放出下一步操作的连接，这样用户可以直接到达需要他进行操作的页面。
/04 提示内容尽可能简短/
文字一多，大多数人都不会逐字逐句看的，甚至有些人会完全不看。
Z哥工作中遇到过无数次这种情况。不管是错误提示还是操作提示，不管你写的多么详细、清楚，只要文字超过2行或者有几十个字以上，很多人看都不看直接截个图发给你，问你该怎么办？
听说有个美国机构做过相关的研究：
如果句子中的单词数不超过8个，读者可以理解其中的100％。
如果句子包含43个单词或更长的单词，则读者的理解力将下降到不足10％。
美国某研究机构
虽然这个研究说的是英文，但是中文也是类似的道理。不过我没找到这个研究的具体出处，不知道真假，但是我觉得这个结论还是很符合常识的。
以上这4点说起来简单，也很好理解，没什么新奇的。但是真正做的时候很多人就把它们抛之脑后了。
当然，比给出合理的错误提示更好的是，避免出现错误。所以你还可以更进一步，提前规避掉一些错误。
比如，
为了避免日期选择超过有效范围，可以对有效范围外的日期设置为禁用状态。
为了避免在信用卡卡号之类的文本框内输入数字以外的字符，做一下输入限制。
为了避免在弱网络下页面无法正常加载而提示错误，可以做缓存，提前预存一些数据在本地。
……
好了，总结一下。
这篇呢Z哥和你分享了我对软件系统抛出的错误提示的看法。我认为好的错误提示需要符合以下4点。
不要提示用户不关心的信息
清楚表达问题原因
给出引导建议
提示内容尽可能简短
如果可以的话，还可以通过做一些前置的限制约束来提前规避掉一些可能发生的异常。
希望对你有所帮助。
推荐阅读：
怎么开会才不浪费时间？
真的是计划赶不上变化吗？
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」
