Java|什么是好的错误消息?讨论一下Java系统中的错误码设计

Java|什么是好的错误消息?讨论一下Java系统中的错误码设计

文章图片

Java|什么是好的错误消息?讨论一下Java系统中的错误码设计

文章图片

Java|什么是好的错误消息?讨论一下Java系统中的错误码设计

文章图片

Java|什么是好的错误消息?讨论一下Java系统中的错误码设计

文章图片



一 什么是好的错误信息(Error Message)? 一个好的Error Message主要包含三个部分:
Context: 什么导致了错误?发生错误的时候代码想做什么? The error itself: 到底是什么导致了失败?具体的原因和当时的数据是什么? Mitigation: 有什么解决方案来克服这个错误 , 也可以理解为 Solutions 听起来还是有点抽象 , 能否给点代码? 刚好有一个 jdoctor 的项目 , 作者来自Oracle Labs[1
样例代码如下:
ProblemBuilder.newBuilder(TestProblemId.ERROR1 StandardSeverity.ERROR \"Hawaiian pizza\") .withLongDescription(\"Pineapple on pizza would put your relationship with folks you respect at risk.\") .withShortDescription(\"pineapple on pizza isn't allowed\") .because(\"the Italian cuisine should be respected\") .documentedAt(\"https://www.bbc.co.uk/bitesize/articles/z2vftrd\") .addSolution(s -s.withShortDescription(\"eat pineapple for desert\")) .addSolution(s -s.withShortDescription(\"stop adding pineapple to pizza\")); 这里的Problem理解为Error没有问题 , 核心主要包括以下几个字段:
context: such as app name component status code , 使用一个字符串描述当时的上下文 , 如应用名称 + 组件名称 +具体的错误状态码等 , 这个由你自己决定 , 当然JSON字符串也可以 , 如 {\"app\":\"uic\" \"component\": \"login\" \"code\":\"111\" description: Long(Short) to describe error 错误描述 , 有Long和Short两者 because/reason: explain the reason with data 详细解释错误的原因 , 当然必须包含相应的数据 documentedAt: error link 错误对应的HTTP连接 , 更详细地介绍该错误 solutions: possible solutions 可能的解决方案 , 如提示访问者检查email拼写是否正确 , 短信的Pass Code是否输入正确等 。有了这些具体的字段后 , 我们理解起来就方便多啦 。
二 错误码(Error Code)的设计 各种错误处理上都建议使用错误码 , 错误码有非常多的优势:唯一性、搜索/统计更方便等 , 所以我们还是要讨论一下错误码的设计 。 网上也有不少错误码的设计规范 , 当然这篇文章也少不了重复造轮子 , 该设计提供给大家参考 , 大家自行判断啊 , 当然也非常欢迎留言指正 。
一个错误码通常包含三个部分:
System/App short name: 系统或者应用的名称 , 如 RST OSS等 。 如果你熟悉Jira的话 , 基本也是这个规范 , Java程序员应该都知道HHH和SPR代表什么吧? Component short name or code: 系统内部的组件名称或者编码 , 如LOGIN AUDIT , 001 这些都可以 , 方便更快地定位错误 。Status code: 错误的状态码 , 这个是一个三位数字的状态码 , 如200 , 404 , 500 , 主要是借鉴自 HTTP Status Code , 毕竟绝大多数开发者都了解HTTP状态码 , 我们没有必要再重新设计 。有了上述的规范后 , 让我们看一下典型的错误编码长什么样子:
OSS-001-404: 你应该知道是OSS的某一组件报告资源没有找到吧 RST-002-500:这个是一个组件的内部错误 UIC-LOGIN-404:这个应该是会员登录时查找不到指定的账号 我们采用应用名缩写 ,组件名或者编码 ,状态值 , 然后以中划线连接起来 。 中划线比较方便阅读 , 下划线有时候在显示的时候理解为空格 。 同时有了标准的HTTP Status Code支持 , 不用参考文档 , 你都能猜一个八九不离十 。错误码设计千万不要太复杂 , 试图将所有的信息都添加进去 , 当然信息非常全 , 但是也增加了开发者理解和使用成本 , 这个可能要做一个取舍 , 当然我也不是说目前这种一键三连(打赏、点赞加转发)的结构就最合理 , 你也可以自行调整 。 有没有做心里研究的同学来说一下 , 这种三部分组成的方式 , 是不是最符合人们的认知习惯?如果超过三部分 , 如4和5 , 人们能记住和使用的概率是不是就下降的非常多?