应继承Exception或RuntimeException，关键看是否需强制捕获：前者用于预期可恢复的业务异常，后者用于程序逻辑错误；避免继承Throwable，构造器须显式调用super，并禁用业务字段与耗时操作。
继承 Exception 还是 RuntimeException？关键看是否强制捕获
Java 自定义异常类的第一步，是决定它属于「检查型异常（checked）」还是「非检查型异常（unchecked）」。这直接决定调用方是否必须用 try-catch 或声明 throws。
-
Exception及其子类 → 检查型异常：编译器强制处理，适合业务中**预期可能出错且调用方应主动应对**的场景（如文件不存在、参数格式非法但可重试） -
RuntimeException及其子类 → 非检查型异常：无需强制捕获，适合**程序逻辑错误或不可恢复的异常状态**（如用户 ID 为空、状态机非法跳转） - 别直接继承
Throwable—— 会绕过 Java 异常分类机制，导致行为不可预测
super(message) 和 super(message, cause) 的调用时机
自定义异常类通常只需覆盖构造函数，把消息和/或原始异常传递给父类。不显式调用 super(...) 会导致丢失堆栈或上下文信息。
public class InsufficientBalanceException extends Exception {
public InsufficientBalanceException(String message) {
super(message); // 必须，否则 message 不生效
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause); // 链式异常的关键，保留原始异常堆栈
}
}
- 只要重写了构造函数，就必须显式调用父类对应构造器
- 如果业务需要包装底层异常（如 DAO 层抛出
SQLException，Service 层转为业务异常），务必用带cause的构造器 - 避免在构造函数里做耗时操作（如日志打印、远程调用），异常实例化应轻量
为什么不要在异常类里加业务字段或方法？
异常对象本质是“错误信号”，不是数据载体。往里面塞 userId、orderId 等字段，看似方便取值，实则破坏语义且引发隐患：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 序列化兼容性风险：字段增减会影响反序列化，尤其在分布式 RPC 场景下
- 违反单一职责：异常该描述“出了什么错”，不该承担“携带上下文数据”的职责
- 掩盖真正问题：调用方可能依赖这些字段做逻辑分支，把错误处理退化成条件判断
- 正确做法：用日志记录上下文（如 SLF4J 的
logger.error("转账失败，用户ID: {}, 订单ID: {}", userId, orderId, ex)），异常本身保持精简
Spring 中如何统一捕获并转换自定义异常？
在 Spring MVC 或 Spring Boot 项目里，不建议每个 Controller 都写重复的 try-catch。用 @ControllerAdvice + @ExceptionHandler 统一处理更可靠：
立即学习“Java免费学习笔记（深入）”；
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(InsufficientBalanceException.class)
@ResponseBody
public ResponseEntity<ApiResponse> handleInsufficientBalance(
InsufficientBalanceException ex) {
return ResponseEntity.status(400)
.body(ApiResponse.error("余额不足", ex.getMessage()));
}
@ExceptionHandler(RuntimeException.class)
@ResponseBody
public ResponseEntity<ApiResponse> handleUnexpected(RuntimeException ex) {
// 记录完整堆栈，但对前端只返回泛化提示
log.error("未预期异常", ex);
return ResponseEntity.status(500)
.body(ApiResponse.error("系统繁忙，请稍后重试"));
}
}
- 确保
@ControllerAdvice类被 Spring 扫描到（通常放在主启动类同包或子包） - 异常处理器顺序很重要：更具体的异常类型（如
InsufficientBalanceException）要放在更通用的（如Exception）之前 - 别在
@ExceptionHandler方法里再抛异常 —— 会触发默认错误页或 500，破坏统一响应结构
InvalidOrderStatusException、ConcurrentUpdateException），也不要靠一个 BusinessException 加 error code 去模拟所有情况 —— 那会让错误处理逻辑越来越难维护。 
