系统错误码定义规则

一、定义错误异常类

/**
 * @author yunpeng.zhao
 * @version $Id TestException.java, v 0.1 2018-08-01 下午1:51 yunpeng.zhao Exp $$
 */
public class TestException extends RuntimeException{
    private static final long serialVersionUID = -5145296679669649729L;

    /**
     * 异常信息,包含必要的上下文业务信息,用于打印日志
     */
    protected String message;

    /**
     * 具体异常码,即异常码code的后3位,由各具体异常实例化时自己定义
     */
    protected String defineCode;

    public TestException(String defineCode) {
        super();
        this.defineCode = defineCode;
    }

    @Override
    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
    }

    public String getDefineCode() {
        return defineCode;
    }

    public void setDefineCode(String defineCode) {
        this.defineCode = defineCode;
    }
}

二、定义错误码常量管理类

/***
 * 错误码和错误信息定义类
 * 1. 错误码定义规则为5为数字
 * 2. 前两位表示业务场景,最后三位表示错误码。例如:100001。10:通用 001:系统未知异常
 * 3. 维护错误码后需要维护错误描述
 * 错误码列表:
 *  10: 通用
 *      001:参数格式校验
 *  11:开户
 *  12: 交易
 *  13: 查询
 *  14: 银行
 *
 * @author yunpeng.zhao
 *
 */
public class TestErrorInfoConstants {
	/**
	 * 错误码与错误描述
	 */
	protected static Map<String,String> error = new HashMap<String, String>();


	public static String getErrorInfo(String defindCode) {
		return error.get(defindCode);
	}

	/**
	 * 构造方法私有化
	 */
	private TestErrorInfoConstants(){}

	/**
	 * 成功
	 */
	public static final String SUCCESS="00000";

	/***********************************************以10开头COMMON START****************************************************************/
	/**
	 *系统未知异常
	 */
	public static final String FAIL="10001";
	/**
	 * 参数异常
	 * **/
	public static final String PARAM_VALIDATE_EXCEPTION = "10002";
	/**
	 * 请求参数转换响应参数异常
	 * **/
	public static final String REQUEST_TO_RESPONSE_EXCEPTION = "10003";
	/***************************************************************************************************************/



	static{
		error.put(SUCCESS, "成功");
		error.put(FAIL, "系统未知异常");
		error.put(PARAM_VALIDATE_EXCEPTION, "请求参数有误");
		error.put(REQUEST_TO_RESPONSE_EXCEPTION, "请求参数转换响应参数异常");
	}

}

三、在业务地处理过程中,抛出异常

/**
     * 请求转换到响应
     * @param requestDTO
     * @param clazz
     * @param <T>
     * @param <R>
     * @return
     */
    public static  <T,R> T covertRequestToResponse(R requestDTO,Class<T> clazz)  {
        try {
            T response =clazz.newInstance();
            BeanUtils.copyProperties(requestDTO,response);

            return response;
        } catch (Exception e) {
            logger.info("请求参数转换到响应参数出现异常:{}",e);
            throw TestException.REQUEST_TO_RESPONSE_EXCEPTION;
        }
    }

 

<think>好的,用户想了解开源项目中错误码的命名规则和最佳实践。首先,我需要回忆一下之前用户提供的引用内容,看看有没有相关的信息。引用[3]提到了错误码的设计案例,里面提到了错误码的管理和优化,比如使用数据库存储错误码,并提供一个后台管理系统。这可能涉及到错误码的命名和分类。 然后,用户提到的是开源项目中的错误码,所以需要考虑到通用性和可维护性。命名规则方面,可能包括结构化的命名方式,比如使用前缀表示模块或服务,再加上具体的错误类型。例如,用户服务可以用USER_开头,后面跟着错误类型如NOT_FOUND或INVALID_INPUT。 最佳实践方面,引用[3]中提到全局错误码的管理,比如错误码的集中存储和动态更新,这可能意味着错误码需要唯一且易于扩展。另外,错误码应该与文档同步,方便开发者查阅,这也是最佳实践的一部分。 还需要考虑错误码的可读性,命名要清晰明确,避免歧义。比如使用全大写下划线分隔的方式,如AUTH_LOGIN_EXPIRED,这样一目了然。同时,错误码分类也很重要,比如按模块、错误级别(客户端错误、服务端错误)来划分。 另外,错误码的版本控制也是一个点,随着项目迭代,错误码可能会有变化,如何管理新旧错误码的兼容性。例如,在API升级时保留旧错误码一段时间,逐步迁移。 可能还需要参考其他开源项目的实践,比如HTTP状态的设计,使用三位数字分段表示不同类型错误,这可以作为借鉴。不过开源项目可能有自己的规范,需要结合具体情况。 总结下来,命名规则要结构清晰、模块化,最佳实践包括集中管理、文档同步、版本控制、可读性等。需要将这些点组织成有条理的回答,并生成相关问题,比如如何设计全局错误码系统,或者如何处理错误码的国际化需求。</think>### 开源项目中错误码的命名规则与最佳实践 #### 一、错误码命名规则 1. **结构化命名** 采用`模块_子模块_错误类型`的分层命名方式,例如: - 用户服务认证错误:`AUTH_LOGIN_EXPIRED` - 订单服务参数错误:`ORDER_INVALID_PARAM` 这种命名方式能快速定位错误来源和类型[^3]。 2. **统一前缀与分类** - 按服务模块划分前缀(如`USER`、`PAYMENT`) - 按错误类型分类(如`INVALID`、`NOT_FOUND`、`CONFLICT`) 例如:`USER_NOT_FOUND`表示用户不存在[^3][^4]。 3. **标准化格式** - 全大写字母+下划线分隔(推荐):`DATABASE_CONNECTION_FAILED` - 或使用驼峰命名法(需团队统一):`DatabaseConnectionFailed` 需与项目整体代风格一致[^1][^2]。 --- #### 二、最佳实践 1. **全局唯一性与集中管理** - 错误码应在全局范围内唯一,通常通过数字编号实现(如`ERR_1001`)。 - 使用独立文件或数据库存储错误码定义,便于动态更新和国际化支持[^3]。 2. **分层设计原则** - **客户端错误(4xx)**:用户输入问题(如`4001`表示参数缺失) - **服务端错误(5xx)**:系统内部问题(如`5001`表示数据库超时) 可参考HTTP状态设计理念[^3]。 3. **文档与代同步** ```markdown ### 错误码列表 | 错误码 | 类型 | 描述 | |-------------|------------|-----------------------| | AUTH_1001 | 客户端错误 | 用户名或密错误 | | ORDER_2003 | 服务端错误 | 支付网关连接超时 | ``` 需在代注释或独立文档中明确说明每个错误码的含义[^3][^4]。 4. **兼容性与版本控制** - 已发布的错误码不可修改或删除,仅允许新增 - 使用语义化版本号标记错误码变更(如`v2.1.0`新增错误码)[^3]。 --- #### 三、典型开源项目实践 1. **Kubernetes** - 使用`<领域>_<错误类型>`格式,如`PodNotFound` - 错误码包含机器可读的`code`字段和人类可读的`message`字段 2. **gRPC** - 预定义标准状态(如`NOT_FOUND=5`) - 支持自定义扩展错误码 3. **Spring Framework** - 通过`@ExceptionHandler`统一映射异常错误码 - 结合国际化资源文件实现多语言错误提示 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值