错误码的好处

傷城~ 2023-02-17 03:24 134阅读 0赞

# 如何优雅的处理程序中的错误？ #

程序在运行过程中，由于网络，并发，误操作等等，难免会出现一些意料之外的问题。直接崩溃或者让使用者感知这个又不太合适，因此对于用户而言，需要一定的人性化的提示、错误描述或修复建议。

但对于开发或维护者而言，如果只有错误提示信息，这些冗长的提示并不能快速定位问题，他们需要的是一个描述错误的关键信息（摘要信息）。

因此需要一种更好的方式来管理程序错误。其中一种比较好的方式便是逻辑层返回错误码给视图层，视图层来展示错误信息/描述。

## 错误码的优势 ##

核心有两个思想 **索引**、**封装**

使用错误码的优势体现在下面几个方面：

*  快速定位问题
    
     *  无论是代码或者日志，直接搜索错误码是非常快速的
 *  利于自动化处理
    
     *  根据日志中的错误码，进行自动化处理或告警
     *  使得接口调用者可以根据错误码做出一定的处理，若只有提示信息，则不能很好的进行。
 *  降低沟通成本、减少信息在沟通、传递时的损耗
    
     *  出错时，如果只根据错误信息描述，在沟通时可能出现偏差，在描述错误信息时可能会出现损耗而出现歧义或疏漏，但使用错误码不会。
 *  利于流程管理
    
     *  可以根据错误码生产文档，可能产生的错误一目了然
 *  提高程序性能
    
     *  由于错误码占用空间一般远小于错误提示信息占用空间，因此无论在网络传输或是程序处理时，效率远远高于错误提示信息
 *  利于版本迭代、升级
    
     *  随着软件升级、版本的迭代，只要错误码还是不变的，即便修改错误描述信息，也不会引起混乱。
 *  利于差异化展示错误信息
    
     *  不同的国家、地区、语言的用户，对于文字的偏好不同，使用错误码可以更轻松的针对用户的喜好修改提示信息。
 *  封装的思想
    
     *  隐藏内部实现、敏感信息，降低软件边界的耦合
 *  利于代码维护
    
     *  如果直接将提示信息写在代码中，一是增加代码体积；二是当软件功能增多时，维护成本将大大提升，而使用错误码时，维护成本增加的没那么快。
     *  对于多人协作的开发模式而言，编码和交互可以由不同的人员专门负责，职责单一，专人办专事。

## 错误码的代价 ##

使用错误码有这么多好处，那么它代价（成本）是怎样的呢？

错误码的代价：

*  引入额外的开发成本
    
     *  需要定义错误码，且不能与已有错误码重复
     *  开发者需要使用错误码表达错误信息，就需要额外维护他们的映射关系以及思维上的转变。
 *  错误信息隐藏
    
     *  无法直接从错误码中获取详细的信息，必须借助错误码文档等映射工具才能获取有用信息。

其实引入错误码的弊端是和好处对应的，在解决一些问题的同时也引入了另外的的问题。

## 结论 ##

虽然看到错误码的优势是远远大于弊端的，但对于个人开发者或者生命周期短的小型软件而言，上面的优势并不明显，直接输出提示则更好。

--------------------

## 如何管理错误码 ##

当软件的功能越来越多时，他的成本也因此升高，因此需要更高效的使用错误码。

### 规范错误码格式 ###

按照一定格式将错误码的分类有利于减少错误码重复/冲突，方便定义错误码，方便快速定位问题。

##### 使用从左到右依次分类、细化 #####

如HTTP协议中第一位是大类分类，剩下的是递增的子类型错误，如看到4xx便关注调用者的错误，看到5xx更关注服务提供者的错误。

##### 压缩错误码长度 #####

大型软件中往往以十六进制串作为错误码，因为同样长度的16进制比10进制的数看起来更简短，更短即更快，无论是表达和转述或是存储。

##### 示例 #####

*  最高一位固定0，使用数字数表示时永远为正数，表达式中没有负号只有数字，避免歧义
 *  第二位0表示系统意料之中的用户输入导致的异常，为1表示系统由于所依赖的基础设施（如网络、系统、其他软件）不能正确响应而导致的错误。
 *  第3-13位标识某一个软件/服务
 *  剩余位数由服务内部定义，可以按照模块等划分

所有错误码都统一按照相同规范划分完毕后，一看到错误码，就可以立刻定位到是系统哪里发生了问题，然后便可以安排对应部分负责人排查。

### 代码中如何选择错误码的类型 ###

在一定规范前提下，C、C++这类基础的程序常常位于底层，与其他程序交互较少或作为提供者，与之交互的系统也通常位数字表达状态，因此使用数字类型更好，如int32比字符串或者枚举占用更少的内存。

而更上层的一些语言，经常与其他系统打交道，更适合用String以获取更好的兼容性，由于一个服务中不同错误码有大量的位重复，有的语言利用了字典树，反而可能更节省空间

--------------------

## 更多 ##

关于错误码远远不止这些，还有更多的问题待我们解决~

### 错误码的使用（落地） ###

合理规范何时必须记录错误码，使用范围。  
如error级别日志必须记录错误码，接口如果不能正确响应，则必须定义错误码等。

### 错误码的管理 ###

如何更高效的维护错误码和异常的映射关系。

*  建立错误码多语言管理平台（录入+查询）
    
     *  如何更高效的录入错误码？
 *  日志分析与告警
    
     *  方案？