自定义Java异常类，业务错误封装方法

本文深入剖析了在Java业务开发中如何科学设计自定义异常类（如BizException），强调业务错误必须与系统崩溃严格区分：通过继承RuntimeException但提供多构造函数（支持消息、异常链、错误码解耦）、统一ErrorCode枚举（纯业务语义、数字编码、与HTTP状态码解耦）、规范日志打印方式（禁用e.printStackTrace()，善用SLF4J参数化日志）等实践，实现错误可识别、可捕获、可追溯、可降级，彻底解决模糊异常边界、事务误回滚、日志难排查、上下游协议耦合等高频痛点，让业务异常真正成为系统健壮性的“显性信号”而非隐藏雷区。

为什么不能直接 throw new RuntimeException("xxx")

业务错误不是程序崩溃，用 RuntimeException 会模糊“预期失败”和“意外崩溃”的边界。调用方无法区分是参数错了还是数据库挂了，更没法针对性捕获重试或降级。

• 所有 RuntimeException 子类默认不强制捕获，下游容易漏处理，上线后才发现订单创建失败却没日志、没告警
• 框架（如 Spring）对 RuntimeException 默认回滚事务，但像“余额不足”这种业务拒绝，不该触发回滚——它根本没改数据库
• 错误码、错误上下文（如订单ID、用户ID）无法结构化携带，日志里只剩一串字符串，排查时得靠猜

自定义异常类必须重写哪些构造函数

Java 异常链和日志打印依赖构造函数签名。只写一个带 String 的构造函数，会导致上游用 new BizException("xxx", e) 时丢失原始异常栈，调试时看不到根因。

• 必须提供 BizException(String message) —— 用于简单提示
• 必须提供 BizException(String message, Throwable cause) —— 用于包装底层异常（如 DAO 层抛出的 SQLException）
• 建议加 BizException(ErrorCode code, String message) —— 把错误码和消息解耦，方便国际化或前端映射

示例：

public class BizException extends RuntimeException {
    private final ErrorCode code;

    public BizException(String message) {
        super(message);
        this.code = ErrorCode.UNKNOWN;
    }

    public BizException(String message, Throwable cause) {
        super(message, cause);
        this.code = ErrorCode.UNKNOWN;
    }

    public BizException(ErrorCode code, String message) {
        super(message);
        this.code = code;
    }
}

ErrorCode 枚举要不要放 HTTP 状态码

不要。HTTP 状态码是协议层概念，和业务语义无关。把 400 塞进 ErrorCode 枚举，会导致 RPC 调用（如 Dubbo、gRPC）或消息队列场景下误用——它们根本不走 HTTP。

• 枚举只管业务维度：比如 ORDER_NOT_FOUND、INSUFFICIENT_BALANCE，值用纯数字（如 1001、1002），和协议解耦
• HTTP 状态码由 Controller 层统一映射：Spring MVC 用 @ControllerAdvice + @ExceptionHandler 根据 ErrorCode 决定返回 400 还是 409
• RPC 场景下，这个枚举可序列化传给下游，对方按码做本地化处理，不用硬编码状态码

log.error() 里要不要打印 e.printStackTrace()

不要。SLF4J 的 logger.error(msg, e) 已自动输出完整栈，多打一次 e.printStackTrace() 会让日志重复、错行，还可能因线程竞争导致日志混乱。

• 正确写法：log.error("创建订单失败，orderNo={}", orderNo, ex); —— 消息清晰，异常对象作为参数传入
• 如果异常是自定义的，确保 getMessage() 返回的是业务友好文案（如“库存不足”，而非“java.lang.NullPointerException”）
• 敏感字段（如手机号、身份证号）要在 getMessage() 中脱敏，别等日志进 ELK 才想起来过滤

复杂点在于：异常类本身要轻量，别在构造时查数据库或远程调用；错误码枚举要集中管理，避免散落在各个 service 里硬编码；还有，别让团队成员开始争论“该继承 Exception 还是 RuntimeException”——只要约定好“所有业务异常都继承 RuntimeException，但必须可被捕获和识别”，就比纠结检查异常更有实际价值。

终于介绍完啦！小伙伴们，这篇关于《自定义Java异常类，业务错误封装方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！