Java自定义异常类的实现与应用_技术教程

应继承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 等字段，看似方便取值，实则破坏语义且引发隐患：

序列化兼容性风险：字段增减会影响反序列化，尤其在分布式 RPC 场景下
违反单一职责：异常该描述“出了什么错”，不该承担“携带上下文数据”的职责
掩盖真正问题：调用方可能依赖这些字段做逻辑分支，把错误处理退化成条件判断
正确做法：用日志记录上下文（如 SLF4J 的 logger.error("转账失败，用户ID: {}, 订单ID: {}", userId, orderId, ex)），异常本身保持精简

Spring 中如何统一捕获并转换自定义异常？

在 Spring MVC 或 Spring Boot 项目里，不建议每个 Controller 都写重复的 try-catch。用 @ControllerAdvice + @ExceptionHandler 统一处理更可靠：

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(InsufficientBalanceException.class)
    @ResponseBody
    public ResponseEntity handleInsufficientBalance(
            InsufficientBalanceException ex) {
        return ResponseEntity.status(400)
                .body(ApiResponse.error("余额不足", ex.getMessage()));
    }

    @ExceptionHandler(RuntimeException.class)
    @ResponseBody
    public ResponseEntity handleUnexpected(RuntimeException ex) {
        // 记录完整堆栈，但对前端只返回泛化提示
        log.error("未预期异常", ex);
        return ResponseEntity.status(500)
                .body(ApiResponse.error("系统繁忙，请稍后重试"));
    }
}

确保 @ControllerAdvice 类被 Spring 扫描到（通常放在主启动类同包或子包）
异常处理器顺序很重要：更具体的异常类型（如 InsufficientBalanceException）要放在更通用的（如 Exception）之前
别在 @ExceptionHandler 方法里再抛异常 —— 会触发默认错误页或 500，破坏统一响应结构

实际用起来最易忽略的是异常类型的传播粒度：同一个业务域内，宁可多定义几个语义清晰的异常类（如 InvalidOrderStatusException、ConcurrentUpdateException），也不要靠一个 BusinessException 加 error code 去模拟所有情况 —— 那会让错误处理逻辑越来越难维护。