This article mainly discusses the design of unified error codes and provides the author's implementation
Welcome to discuss and correct.
The design of this error code is in the warehouse:
github:https://github.com/valarchie/AgileBoot-Back-End
gitee:https://gitee.com/valarchie/AgileBoot-Back-End
Advantages of Unified Error Code Management
- Unified error code description, if there is no unified error code, the error descriptions are scattered in different places in the project, and the same error code produces different error descriptions, which will lead to ambiguity.
- The level of the error code, in the process of interacting with the client, we may need to do different displays according to the level of the error. For example, for errors inside the system, we generate a red alert box. Business operation type errors (such as username cannot exceed 64 bits), we
Then a normal yellow prompt box is used to remind the user. - Handling of i18n. Unified error code management makes internationalization better. We can define a unique key for each error code to find error descriptions corresponding to different languages.
- Centralized error code management facilitates documentation for callers' reference. For example, we provide an interface for other teams to call and provide them with a detailed list of error codes.
Error-free code design flaws
Ruoyi Project
- Error descriptions are scattered in various parts of the project. Once there is a need to change the error description, the project should be searched for the associated error description, and then modified one by one. This situation can easily lead to omissions.
- If translation is required, this arbitrary string form is also difficult to do international translation.
- There is no exact error code, and in some cases, the caller needs to handle the error code you return differently. If there is no accurate error code, it is more difficult to realize only based on the error description.
Error code level
The hierarchy of error codes helps clients handle different levels of errors. For example, some errors are hidden, and some errors are directly exposed to the user. Here I have planned four layers of error codes.
Error code collection
- 1~9999 are reserved error codes or common error codes
- 10000~19999 are internal error codes
- 20000~29999 Client error code (errors such as abnormal client calls)
- 30000~39999 is the third-party error code (the code is normal, but the third-party is abnormal)
- 40000~49999 is the business logic error code (no exception, the code flows normally, and returns a prompt to the user)
error code module
In order to better classify, the author has set up modules for the error codes, which is convenient for the special processing of the client. For example, the client can specifically handle the errors of a certain module in a unified manner.
The numbers corresponding to the modules are in thousands and hundreds. For example, 1XX01, XX represents the meaning of the module.
/**
* modules in the system
*/
public enum Module {
/**
* common module
*/
COMMON(0),
/**
* permission module
*/
PERMISSION(1),
/**
* login module
*/
LOGIN(2),
/**
* database module
*/
DB(3),
/**
* upload
*/
UPLOAD(4),
/**
* user
*/
USER(5),
/**
* configure
*/
CONFIG(6),
/**
* Position
*/
POST(7),
;
private final int code;
Module(int code) { this.code = code * 100; }
public int code() {return code; }
}
Error code example
/**
* 10000~19999 It is an internal error code such as a problem with the framework, etc.
*/
public enum Internal implements ErrorCodeInterface {
/**
* Internal error code
*/
INVALID_PARAMETER(Module.COMMON, 1, "parameter exception"),
UNKNOWN_ERROR(Module.COMMON, 2, "Unknown exception, Please check the system log"),
GET_ENUM_FAILED(Module.COMMON, 3, "Failed to get enum type, enum class: {}"),
GET_CACHE_FAILED(Module.COMMON, 4, "Failed to get cache"),
LOGIN_CAPTCHA_GENERATE_FAIL(Module.LOGIN, 1, "Verification code generation failed"),
INVALID_TOKEN(Module.PERMISSION, 1, "token abnormal"),
DB_INTERNAL_ERROR(Module.DB, 1, "Database exception: {}"),
;
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;
}
}
Use of error codes
In order to facilitate the use of error codes when writing code, I created the class ErrorCode, and put four levels of error classes into this class.
example in code
if (roleService.checkRoleNameUnique(getRoleId(), getRoleName())) {
throw new ApiException(ErrorCode.Business.ROLE_NAME_IS_NOT_UNIQUE, getRoleName());
}
Called in the form: ErrorCode.Business.ROLE_NAME_IS_NOT_UNIQUE
Design flaw in this error code
The flaws are:
- The number of error codes in a module is 100.
There are two ways to solve this problem. One is: try to design a more general error code, too fine-grained will lead to insufficient error code. The second is: use duplicate modules, such as the original User module, and create a User2 module.