最近读了一篇文章, 读了之后感觉收获许多, 遂记录一下。编程最难的地方在于如何处理非预期行为, 这里也是最考验功力的地方。一个好的错误信息, 需要使用简短的信息描述错误是怎么发生的, 发生的原因是什么, 如何处理它。在这篇文章中,作者会告诉你如何返回一个优雅的错误信息。
作者认为好的错误信息应该包含以下三个方面：
- Context「上下文」：是什么导致的这个错误? 当错误发生时, 代码准备做什么？
- The error itself「错误本身」：这个错误究竟是什么？
- Mitigation「如何处理」：怎么样才能避免这个错误？
Context
一个好的 message 就像在描述一个故事, 如果要讲好一个故事就需要描述故事背景。这里的 context 就是 message 的背景。需要告诉开发者, 是什么原因导致的这个错误, 当时的状态是什么样子的, 代码在做什么的时候发生了错误。看下面一个 case:
Couldn’t parse config file
它告诉开发者, 无法解析配置文件, 只是告诉你我遇到了一个无法解析的配置文件。在这个 case 中, 它上下文是缺失的, 到底是哪个配置文件无法被解析呢？修改一版：
Couldn’t parse config file: /etc/sample-config.properties
The error itself
确定好上下文之后, 需要描述错误本身。目前已经知道无法解析 smaple-config.properties 这个配置文件, 但是在解析的时候究竟遇到了什么问题呢？应使用简短的信息描述错误本身, 例如：
Couldn’t parse config file: /etc/sample-config.properties; given snapshot mode 'nevr' isn’t valid
Mitigation
目前, 已经能清楚的告诉开发者什么情况下发生了错误, 具体的错误是什么。最后, 需要告诉开发者如何避免这个错误的发生或者怎么处理这个错误, 毕竟发生错误都是影响系统正常运行的。接着上面的 case 进行补充:
Couldn’t parse config file: /etc/sample-config.properties; given snapshot mode 'nevr' isn’t valid(must be one of 'initial', 'always', 'never') 核心原则是：不应该让开发者面对这个错误之后一无所知，不知道怎么处理这个错误。没有什么比 ‘internal error’ 更让人崩溃了
