Java|什么是好的错误消息？讨论一下Java系统中的错误码设计( 四 ) https|程序员|example

六 FAQ 1 为何选择3位的HTTP Status Code作为Error的Status Code？
大多数开发者对HTTP Status Code都比较熟悉，所以看到这些code就大致明白什么意思，当然对应用开发者也有严格的要求，你千万别将404解释为内部错误，如数据库连接失败这样的，逆正常思维的事情不要做。 HTTP status code归类如下，当然你也可以参考一下 HTTP Status Codes Cheat Sheet[2
。
Informational responses (100–199) Successful responses (200–299) Redirection messages (300–399) Client error responses (400–499) Server error responses (500–599) 但是Error Status Code不局限在HTTP Status Code ，你也可以参考SMTP ，POP3等Status Code ，此外你也自行可以选择诸如007 ， 777这样的编码，只要能解释的合理就可以啦。
在日常的生活中，我们会使用一些特殊意义的数字或者和数字谐音，以下是一些友情提醒：
UIC-LOGIN-666: 太顺利啦，完美登录。但是你团队中有欧美老外的话，他可能理解为理解为恶意登录，登录失败 APP-LOGIN-062: 如果你团队有杭州土著的话，不要使用62这个数字 APP-001-013: 如果该error code要透传给最终用户，请不要使用13这个数字，会引发不适这种有特殊意义的数字或者数字谐音，如520 ， 886 ， 999 ， 95等，如果能使用的恰当非常方便理解或更友好，如透传给用户UIC-REG-200(注册成功) ，如果调整为UIC-REG-520可能更温馨一些。总的来说使用这些数字要注意场景，当然比较保险的做法就是参考HTTP ， SMTP等设计的status code 。
2 properties文件存储error code和message ，真的比enum和POJO好吗？
就Java和IntelliJ IDEA的支持来看，目前的配合还是比较好的，如i18n ，维护成本等，而且这些ErrorMessages.properties也可以提交到中心仓库进行Error Code集中管理，如果是Java Enum+POJO对i18n和集中管理都比较麻烦，而且代码量也比较大，你从上述的jdoctor的problem builder的就可以看出。当然在不同的语言中也未必是绝对的，如在Rust中，由于enum的特性比较丰富，所以在Rust下使用enum来实现error code可能是比较好的选择。
#[derive(Debug)
enum ErrorMessages { AppLogin404 { email: StringAppLogin405(String)impl fmt::Display for ErrorMessages { fn fmt(self f:mut fmt::Formatter) -fmt::Result { // extract enum name parameter // output message from java-properties write!(f \"{:?\" self)3 为何不在Error Code中提供错误级别
不少错误码设计中会添加错误级别，如 RS-001-404-9 这样，最后一位表示错误的严重级别。这样做没有问题，但是也要考虑现实因素，如下：
错误的级别会动态调整的：如随着时空的变化，之前非常严重的错误级别，现在并不那么严重啦。如果资源找不到可能之前非常严重，但是现在添加了备份方案，可以从备份服务器中再查找一次，所以这个错误出现在主服务上可能现在就不是那么严重啦。不同团队对错误级别的认知不一样：如OSS-404在OSS团队的data server上找不到，元信息都是有的，结果在data server上没有找到对应的数据，这个是非常严重的错误。雷卷在业务团队，如负责Serverless Jamstack ，其中的一个文件缺失，如html css image ，可能并不是一个大问题，等一会重试下，不行就再上传一下。我想表达的是同样的错误，在不同团队中的重要性并不一样。如果将错误的基本固化到error code中，这个后续你就没法调整啦，你如果调整了错误级别，那就是可能就是另外一个错误码，给统计和理解都会造成问题。我个人是建议错误码中不要包括严重级别这些信息，而是通过外围的文档和描述进行说明，当然你也可以通过诸如 log.infolog.error来确定错误的级别。