「这是我参与2022首次更文挑战的第21天，活动详情查看：2022首次更文挑战」
设计目的
所有的后端接口都无论成功失败都会有一个规范的返回值，规范化返回值不仅是为了增加代码可读性，也是为了提高问题排查效率，通过错误码快速定位问题所在。
所以，目的就是为了：
- 统一模块管理，规范化
- 解决多种异常处理抛出
- 便于后期监控错误信息，快速定位错误位置
使用场景：
- 通过错误码配置监控大盘。
- 通过日志进行问题排查，快速定位问题。
- 后端服务之间错误码传递。
- 前端展示的错误提示/OpenAPI。
返回格式：
{
code: 1111,
message: "调用是比啊"
data: null
}
详细设计
错误类型，主要通过工厂模式进行设计。先实现一个错误基类，并定义基本的方法，然后其他错误类继承基类实现其他的错误类型类，重写基本的方法或者自己定义一些自己的方法。
- 支持细粒度的错误定义
- 通过模块划分清晰的错误类别
- 不同系统之间的共性
public abstract class BaseError extends Error {
public code: number;
public data: any;
protected constructor(code: number, message: string, data?: any) {
super(message);
this.code = this.getPreCode() + code;
this.data = data;
}
// 抽象方法，由子类实现，获取模块异常前缀代码
protected abstract getPreCode(): string;
/**
* static get USER_NOT_EXIST(){
return new BaseError(10000,"用户不存在")
}
*/
}
错误规范
- 错误编码（ 7 位），格式：前缀码 +错误类型（ 2 位）+具体业务错误码（ 3 位 ）
- 范例：A10001、B10001
- 模块编码：
- 业务模块1错误码，前缀码：A
- 业务模块2错误码，前缀码：B
- 业务模块3错误码，前缀码： C
- 业务模块3错误码，前缀码： D
- 第三方错误码 ，模块码：E
- 错误类型：
- 参数错误 10
- 业务错误 20
- 系统错误 30
- 数据库错误 40
- 其他错误 50 具体错误码使用范例：
- 缺少 id 参数 A10001
- 缺少 name 参数 B10002
