当前位置 : 主页 > 编程语言 > java >

AgileBoot 项目内统一的错误码设计分析

来源:互联网 收集:自由互联 发布时间:2023-01-30
目录 引言 统一的错误码管理的优点 无错误码设计的缺陷 Ruoyi项目 错误码的层级 错误码的模块 错误码代码例子 错误码的使用 该错误码的设计缺陷 引言 本篇文章主要探讨关于统一错误
目录
  • 引言
  • 统一的错误码管理的优点
  • 无错误码设计的缺陷
    • Ruoyi项目
    • 错误码的层级
    • 错误码的模块
    • 错误码代码例子
    • 错误码的使用
    • 该错误码的设计缺陷

引言

本篇文章主要探讨关于统一错误码的设计,并提供笔者的实现

欢迎大家讨论,指正。

该错误码的设计在仓库:

github:github.com/valarchie/A…

gitee:gitee.com/valarchie/A…

统一的错误码管理的优点

  • 统一的错误码描述,如果没有统一的错误码的话,错误描述散落在项目内的不同地方,同一个错误码却产生不同的错误描述,会导致歧义。
  • 错误码的层级,在与客户端的交互过程中,我们可能需要根据错误的层级,来做不同的显示。例如系统内部的错误,我们产生红色的警告框。业务上操作类型的错误(例如用户名不能超过64位),我们 则以正常的黄色提示框来提醒用户。
  • i18n的处理。统一的错误码管理,才使得国际化更好实现。我们可以给每一种错误码定义唯一的key,来找到对应不同语言的错误描述。
  • 集中的错误码管理便于形成文档供调用者参考。例如我们提供接口给其他团队调用,可以提供给他们详细的错误码列表。

无错误码设计的缺陷

Ruoyi项目

  • 错误描述散落在项目的各个地方,一旦有改变错误描述的需求,要满项目去寻找关联的错误描述,然后逐一修改。这种情形很容易造成疏漏。
  • 如果需要翻译的话,这种随意的字符串形式也很难去做国际化翻译。
  • 没有准确的错误码,在一些情形下,调用方需要根据你返回的错误码进行不同的处理。如果没有准确的错误码,仅凭错误描述,比较难以实现。

错误码的层级

错误码的层级有助于客户端对于不同级别的错误进行处理。比如有的错误进行隐藏,有的错误直接暴露给用户。这边我规划了四层错误码。 错误码集合

  • 1~9999 为保留错误码 或者 常用错误码
  • 10000~19999 为内部错误码
  • 20000~29999 客户端错误码 (客户端异常调用之类的错误)
  • 30000~39999 为第三方错误码 (代码正常,但是第三方异常)
  • 40000~49999 为业务逻辑 错误码 (无异常,代码正常流转,并返回提示给用户)

错误码的模块

为了更好的分门别类,笔者给错误码设定了模块,便于客户端的特殊处理。例如客户端可以专门给某一个模块的错误进行一个统一的处理。 模块对应的数字在千位和百位。例如1XX01,XX代表了模块的意义。

/**
 * 系统内的模块
 */
public enum Module {
    /**
     * 普通模块
     */
    COMMON(0),
    /**
     * 权限模块
     */
    PERMISSION(1),
    /**
     * 登录模块
     */
    LOGIN(2),
    /**
     * 数据库模块
     */
    DB(3),
    /**
     * 上传
     */
    UPLOAD(4),
    /**
     * 用户
     */
    USER(5),
    /**
     * 配置
     */
    CONFIG(6),
    /**
     * 职位
     */
    POST(7),
    ;
    private final int code;
    Module(int code) { this.code = code * 100; }
    public int code() {return code; }
}

错误码代码例子

/**
     * 10000~19999是内部错误码  例如 框架有问题之类的
     */
    public enum Internal implements ErrorCodeInterface {
        /**
         * 内部错误码
         */
        INVALID_PARAMETER(Module.COMMON, 1, "参数异常"),
        UNKNOWN_ERROR(Module.COMMON, 2, "未知异常, 请查看系统日志"),
        GET_ENUM_FAILED(Module.COMMON, 3, "获取枚举类型失败, 枚举类: {}"),
        GET_CACHE_FAILED(Module.COMMON, 4, "获取缓存失败"),
        LOGIN_CAPTCHA_GENERATE_FAIL(Module.LOGIN, 1, "验证码生成失败"),
        INVALID_TOKEN(Module.PERMISSION, 1, "token异常"),
        DB_INTERNAL_ERROR(Module.DB, 1, "数据库异常: {}"),
        ;
        private final int code;
        private final String msg;
        private static final int BASE_CODE = 10000;
        Internal(Module module, int code, String msg) {
            this.code = BASE_CODE + module.code() + code;
            this.msg = msg;
        }
        @Override
        public int code() {
            return this.code;
        }
        @Override
        public String message() {
            return this.msg;
        }
    }

错误码的使用

为了便于错误码在编写代码时方便使用,我创建了ErrorCode这个类,并将四个层级的错误类一并放进这个类当中。

代码中的例子

 if (roleService.checkRoleNameUnique(getRoleId(), getRoleName())) {
            throw new ApiException(ErrorCode.Business.ROLE_NAME_IS_NOT_UNIQUE, getRoleName());
 }

通过这样的形式进行调用:ErrorCode.Business.ROLE_NAME_IS_NOT_UNIQUE

该错误码的设计缺陷

缺陷在于:

  • 一个模块内的错误码上线是100个。 解决该问题的话,有两种形式。一是:尽量设计比较通用的错误码,粒度过细会导致错误码不够用。二是:使用重复的模块,比如原来User模块,再起一个User2模块。

探讨关于错误码的设计,欢迎小伙伴留言评论指正。

Any corrections or suggestions are appreciated.

Agileboot是一个致力于规范、质量,健壮的前后端开发脚手架。

以上就是AgileBoot 项目内统一的错误码设计分析的详细内容,更多关于AgileBoot 项目内统一错误码的资料请关注自由互联其它相关文章!

网友评论