Java自定义异常设计与实现方法

golang学习网今天将给大家带来《Java自定义异常信息设计指南》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

应继承RuntimeException并定义带errorCode和context的异常基类， errorCode用枚举或常量，保留原始异常链，变量存context而非message，重写toString以输出关键信息。

Java里异常信息不是靠“拼字符串”临时凑出来的，而是要通过自定义异常类把错误码、业务上下文、原始异常链一起固化进去——否则日志里全是 "null pointer" 或 "illegal argument"，根本看不出是“用户余额不足”还是“优惠券已过期”。

怎么让异常自带错误码和业务语义？

别再用 throw new RuntimeException("余额不足") 这种写法。它没法区分场景，前端也不能靠字符串匹配提示文案。正确做法是定义带 errorCode 字段的异常基类：

public abstract class BaseException extends RuntimeException {
    private final String errorCode;
    private final Map context = new HashMap<>();

    protected BaseException(String errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }

    protected BaseException(String errorCode, String message, Throwable cause) {
        super(message, cause);
        this.errorCode = errorCode;
    }

    public String getErrorCode() { return errorCode; }
    public Map getContext() { return context; }
}

• errorCode 必须是枚举或常量（如 USER_INSUFFICIENT_BALANCE），不能是硬编码字符串
• 构造时传入 cause，才能保留原始异常堆栈，避免丢失关键线索
• 用 context 存订单号、用户ID等现场数据，排查时直接可查，不用翻日志找关联字段

该继承 Exception 还是 RuntimeException？

绝大多数业务异常必须继承 RuntimeException。受检异常（extends Exception）在分层调用中会强制上层加 throws，导致 Service 层、Controller 层到处都是异常声明，严重污染接口契约。

• 只有极少数场景适用受检异常：比如调用银行支付 SDK 时，必须确保调用方显式处理“签名失败”这类不可忽略的集成错误
• Spring 全局异常处理器（@RestControllerAdvice）只捕获 RuntimeException 及其子类，继承 Exception 的异常会被绕过
• 如果误用受检异常，你会看到 Controller 返回 500，但全局异常处理器压根没触发——因为 Spring 默认不拦截受检异常

异常消息里能不能拼接变量？

可以，但禁止在 message 字段里直接拼接敏感或动态值（如密码、token、完整 SQL）。正确做法是把变量放进 context，消息保持静态可读：

// ✅ 好：message 固定，变量走 context
throw new BusinessException("USER_LOGIN_FAILED", "登录失败")
    .withContext("username", username)
    .withContext("ip", request.getRemoteAddr());

// ❌ 坏：message 含变量，日志聚合失效、安全风险、i18n 难做
throw new BusinessException("USER_LOGIN_FAILED", "登录失败: 用户 " + username + " 从 " + ip + " 登录");

• 静态 message 方便 ELK 按模板聚合错误频次；动态拼接会导致每条日志 message 都不同，无法统计
• context 中的值可被日志框架自动脱敏（如屏蔽手机号中间四位），message 里的内容则无法控制
• 国际化时，message 是 key，变量由前端或 i18n 工具注入，而不是后端硬拼

最常被忽略的一点：异常类本身要实现 toString() 或重载日志输出逻辑，否则打印异常时看不到 errorCode 和 context ——它们就只是藏在对象深处的摆设。

今天关于《Java自定义异常设计与实现方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！