如何在 Java 中利用 对象导向的异常处理 自定义业务异常类并传递丰富的错误元数据

Ja va中自定义业务异常，听着像是小事一桩，但其实门道挺多。你得想一个问题：抛出异常到底是为了什么？不是为了让程序挂掉，而是要把"出什么事了、为什么出、该怎么处理"这一串信息，清清楚楚地传递给调用方。

所以关键不在于"抛不抛"，而在于"怎么封装、怎么传递、怎么用"。

明确继承 RuntimeException，避免强制捕获

业务异常属于运行时异常，和普通的 IOException 这类检查异常不同，它不应该逼着调用方写 try-catch。直接继承 RuntimeException 是最稳妥的选择：

• 不会污染调用方的代码流，不会打断正常的业务逻辑
• Service 层可以干净地抛出，不用堆砌一堆无意义的 try-catch 块
• 和 Spring 的声明式事务天然兼容（默认对 RuntimeException 回滚）

一句话：它是 REST API 失败响应的好搭档，不会给上层代码带来额外负担。

携带结构化元数据：错误码 + 消息 + 可选扩展字段

只靠一个 message 字符串，那信息密度太低了。前端要猜，日志要猜，链路追踪也要猜。推荐在异常类中固化这几个字段：

• code：字符串或整型错误码（比如 "USER_NOT_FOUND" 或 40401），前端拿到直接 switch 分支处理，清晰明了
• message：面向用户的可读描述（支持 i18n 占位符，比如 "用户 {id} 不存在"）
• details（可选）：Map 类型，用来存放上下文数据（比如 {"userId": 123, "requestId": "req-abc"}），方便排查
• timestamp（可选）：记录异常发生时刻，辅助链路追踪

构造时建议优先使用枚举（比如 RespStatus.USER_NOT_FOUND），这样 code 和 message 的一致性有保障，避免硬编码散落在项目各处。

必须保留原始异常链（cause）

业务异常不是终点，它是错误信息的"翻译层"。比如 DAO 抛出了 SQLException，Feign 抛出了 HttpClientErrorException，都应该作为 cause 传入业务异常：

• 构造函数中显式接收 Throwable cause 参数
• Service 层 catch 后，用 new BusinessException(code, msg, e) 包装再抛出
• 全局异常处理器中，日志打印必须带 cause：log.error("业务异常[{}]", ex.getCode(), ex)（注意第三个参数才是异常对象）

这样排查问题时，一眼就能看到业务含义（"库存不足"），又能顺着链路找到根因（"MySQL Deadlock found"）。这才是从根子上查问题的正确姿势。

配合全局处理器统一输出格式

在 @RestControllerAdvice 中拦截自定义异常，只返回精简、协议友好的 JSON：

• 响应体仅包含 code、msg、timestamp（或 requestId）
• 不暴露堆栈，不返回 cause 的 toString()，防止敏感信息泄露
• 其他异常（比如空指针、NPE）走兜底逻辑，返回通用 500 错误

前端收到 {"code":"ORDER_TIMEOUT","msg":"订单已超时，请重新下单"}，就能精准展示提示，无需去解析那个模糊的 "Internal Server Error"。