从“捕获侠”到“架构师”：重构你的 Java 异常防御体系

🚩 开场白

在座的各位 Java 开发者，想必都经历过半夜被线上报警叫醒的恐惧。那个红色的 NullPointerException 或者找不到堆栈的 Unknown Error，往往是我们噩梦的开始。

很多同学处理异常的手段还停留在“三板斧”：

1. try-catch 包住完事。
2. e.printStackTrace() 打印在控制台。
3. 实在不行返回个 null。

今天，我们将通过三个回合的攻防演练，剖析典型烂代码，建立最佳实践，并引入设计模式来优雅地治理异常。

---

🥊 第一回合：扫雷行动 —— 典型“烂代码”鉴赏

在谈架构之前，我们先得学会“避坑”。请看以下三个经典的“异常犯罪现场”。

❌ 罪状一：生吞异常 (The Silencer)

try {
    fileService.read(path);
} catch (IOException e) {
    // TODO: 之后处理
}

• 后果： 线上业务中断，但日志静悄悄，排查问题全靠猜。
• 修正： 要么处理，要么抛出，绝不沉默。 即使不处理，也要 log.error 记录完整堆栈。

❌ 罪状二：丢失案发现场 (The Evidence Destroyer)

try {
    userDao.find(id);
} catch (SQLException e) {
    throw new RuntimeException("数据库挂了"); // 原始异常 e 丢了！
}

• 后果： 你知道数据库挂了，但不知道是 SQL 写错了、连接池满了还是网络断了。
• 修正： throw new RuntimeException("数据库异常", e); —— 异常链（Chaining） 是保留案发现场的关键。

❌ 罪状三：控制流滥用 (The Flow Control Abuse)

try {
    item = list.get(index);
} catch (IndexOutOfBoundsException e) {
    item = null; // 用异常来做逻辑判断
}

• 后果： 性能极差（创建异常对象需要填充堆栈），代码可读性低。
• 修正： 使用 if (index < list.size()) 进行防御性编程。异常应该用于“异常情况”，而不是正常流程。

---

🛡️ 第二回合：战术升级 —— 最佳处理方案

扫清了障碍，我们需要建立一套标准的战术体系。在现代 Java 开发（尤其是 Spring Boot 环境）中，我们推崇以下原则：

1. 受检 vs 非受检 (Checked vs Unchecked) 的终极抉择

• 传统观念： 强制开发者处理错误（Checked Exception）。
• 现代实战： 优先使用 RuntimeException（Unchecked）。
• 理由： 大多数业务异常（如数据库连接失败、参数错误）是代码无法自动恢复的。强制 catch 只会产生大量样板代码。
• 策略： 将 SQL 异常、IO 异常包装为自定义的 BusinessException (继承自 RuntimeException) 向上抛出，由顶层统一捕获。

2. 定义你的“异常字典”

不要全盘抛出 RuntimeException。请定义清晰的业务异常体系：

// 基础业务异常
public class BaseBizException extends RuntimeException {
    private final ErrorCode errorCode;
    // ...
}

// 细分场景
public class UserNotFoundException extends BaseBizException { ... }
public class InsufficientBalanceException extends BaseBizException { ... }

这样做的目的是为了让上层调用者（或全局处理器）能根据类型做出不同的响应（比如返回不同的 HTTP 状态码）。

---

🧩 第三回合：降维打击 —— 设计模式与全局治理

这是本次分享的“核武器”。当异常处理上升到架构层面，我们就不再是在每个方法里写 try-catch，而是使用设计模式。

1. 全局异常处理器 (Global Exception Handler) —— 责任链模式的变体

在 Spring Boot 中，这是标配。我们将异常处理逻辑从业务代码中剥离，通过 AOP 切面统一拦截。

@RestControllerAdvice
@Slf4j
public class GlobalExceptionHandler {

    // 处理特定业务异常
    @ExceptionHandler(BaseBizException.class)
    public Result<?> handleBizException(BaseBizException e) {
        log.warn("业务异常: {}", e.getMessage());
        return Result.fail(e.getErrorCode());
    }

    // 兜底策略：处理所有未预见的异常
    @ExceptionHandler(Exception.class)
    public Result<?> handleSystemException(Exception e) {
        log.error("系统崩溃: ", e); // 必须记录堆栈！
        return Result.fail(ErrorCode.INTERNAL_SERVER_ERROR);
    }
}

• 设计美学： 业务代码只管抛出，Handler 只管处理，实现了完美的关注点分离（Separation of Concerns）。

2. 模板方法模式 (Template Method) —— 消除重复代码

如果你发现自己在很多地方写重复的 try-catch（比如事务回滚、资源关闭），可以使用模板方法或 Lambda 包装。

// 定义一个执行器
public static <T> T execute(Supplier<T> action) {
    try {
        return action.get();
    } catch (SpecificException e) {
        throw new BizException("转换异常", e);
    } catch (Exception e) {
        throw new SystemException("未知错误", e);
    }
}

// 业务代码瞬间清爽
User user = execute(() -> userRepository.find(id));

3. Result 模式 —— 像函数式编程一样思考

在微服务间调用时，抛出异常可能会带来性能开销和反序列化问题。有些团队开始采纳 Vavr 库的 Try 或类似 Rust 的 Result<T, E> 模式。

// 不抛出异常，而是返回一个包含“成功值”或“错误信息”的对象
Result<User> result = userService.findUser(id);

if (result.isSuccess()) {
    handle(result.getData());
} else {
    log.error(result.getError());
}

这是一种更显式的错误处理方式，强迫调用者必须处理可能的失败，而不是假装它不存在。

---

🏁 总结：异常处理的三个境界

我们一起经历了三个境界：

1. 第一境： 手忙脚乱。到处 try-catch，日志乱飞，生吞异常。
2. 第二境： 井井有条。学会了自定义异常，区分了 Checked/Unchecked，保留了堆栈。
3. 第三境： 大道至简。利用全局处理器和设计模式，让业务代码中几乎看不到 try-catch，异常成为流转于系统中的一种“消息”。

最后送大家一句话：

优秀的程序员，不仅写得出顺畅的 Happy Path（快乐路径），更能在 Sad Path（异常路径）上通过优雅的代码，给予系统最大的韧性。