Java 异常处理最佳实践，别再乱用 try-catch

砍材农夫
0 阅读1分钟

在实际开发中，异常处理往往是被忽视但又极其重要的一环。滥用 try-catch 不仅会让代码变得臃肿难读，还可能掩盖潜在的问题。下面总结一套 Java 异常处理最佳实践，帮助你写出更优雅、更健壮的代码。

1. 理解异常体系，用对类型

Java 的异常分为三类：

  • Checked Exception（受检异常）：如 IOException、SQLException，必须显式处理（try-catch 或 throws）。通常表示可恢复的外部错误。
  • Unchecked Exception（非受检异常）：如 NullPointerException、IllegalArgumentException，是 RuntimeException 的子类，不强制处理。通常表示程序缺陷，不应捕获后继续执行。
  • Error：如 OutOfMemoryError，是 JVM 内部错误，应用层几乎不应该捕获。

✅ 最佳实践：

  • 对 Checked Exception 谨慎处理 —— 能恢复就处理，不能恢复就封装后抛出。

  • 对 RuntimeException 不要主动捕获，除非你能真正处理（如重试、降级）。

  • 永远不要捕获 Error。

    // ❌ 错误示例 try { // 业务代码 } catch (Exception e) { // 吞掉所有异常 // 空处理 }

2. 尽早抛出，晚点捕获（Throw Early, Catch Late）

  • Throw Early：参数校验、状态检查应尽早进行，快速失败（fail-fast）。

  • Catch Late：只有在有明确处理逻辑（如回滚、重试、转换异常）时才捕获，否则让异常向上抛出。

    // ✅ 示例：参数校验提前抛出 public void transfer(Account from, Account to, BigDecimal amount) { if (from == null || to == null || amount == null) { throw new IllegalArgumentException("参数不能为空"); } if (amount.compareTo(BigDecimal.ZERO) <= 0) { throw new IllegalArgumentException("金额必须大于0"); } // 业务逻辑 }

3. 不要吞掉异常（Never Swallow Exception）

捕获异常后什么都不做，是最危险的行为。

// ❌ 致命错误
try {
    // 业务代码
} catch (IOException e) {
    // 吞掉异常
}

✅ 正确处理方式：

  • 记录日志

  • 重新抛出业务异常

  • 返回明确的错误码/响应

    try { // 业务代码 } catch (IOException e) { log.error("文件读取失败，文件路径: {}", path, e); throw new BusinessException("文件处理失败", e); }

4. 使用 try-with-resources 管理资源

对于实现了 AutoCloseable 的资源（如流、连接），优先使用 try-with-resources，它会自动关闭资源，避免资源泄漏。

// ✅ 推荐
try (FileInputStream fis = new FileInputStream("file.txt");
     BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
    // 读取文件
} catch (IOException e) {
    log.error("读取文件失败", e);
}

避免手动在 finally 中关闭，容易遗漏或出错。

5. 异常链与上下文信息

捕获异常后重新抛出时，不要丢失原始异常，使用 initCause 或构造函数传递 cause。

// ❌ 丢失原始异常
try {
    // 数据库操作
} catch (SQLException e) {
    throw new BusinessException("数据库错误");
}

// ✅ 保留原始异常
try {
    // 数据库操作
} catch (SQLException e) {
    throw new BusinessException("数据库错误", e);
}

同时，异常信息中应包含足够的上下文（如 ID、参数值），方便定位问题。

throw new BusinessException(String.format("用户[%s]转账失败，金额: %s", userId, amount), e);

6. 区分业务异常与系统异常

  • 业务异常：如余额不足、用户不存在，应定义为受检异常或自定义 RuntimeException，由业务层处理并返回友好提示。
  • 系统异常：如数据库连接失败、第三方接口超时，应在底层封装后抛出，由统一异常处理机制捕获并返回统一错误响应。

✅ 推荐：使用统一异常处理器（如 Spring 的 @RestControllerAdvice）统一处理异常，避免到处 try-catch。

7. 不要用异常控制业务流程

异常处理的性能开销较大，且会破坏代码可读性。

// ❌ 用异常控制流程
try {
    userService.findUser(id);
} catch (UserNotFoundException e) {
    // 新建用户
}

// ✅ 改用条件判断
Optional<User> userOpt = userService.findUser(id);
if (userOpt.isEmpty()) {
    // 新建用户
}

8. 合理定义自定义异常

  • 自定义异常应继承合适的父类（通常为 RuntimeException，除非强制调用方处理）。

  • 不要为了“省事”定义一个 BaseException 然后到处使用，应按场景细分。

    // ✅ 示例 public class BusinessException extends RuntimeException { private final String errorCode;

    public BusinessException(String errorCode, String message) {
    super(message);
    this.errorCode = errorCode;
}

public BusinessException(String errorCode, String message, Throwable cause) {
    super(message, cause);
    this.errorCode = errorCode;
}

    }

9. 日志记录的原则

  • 在异常被捕获并处理的地方记录日志，避免重复记录。

  • 使用 log.error 时带上异常对象，否则只会记录 message，丢失堆栈。

    // ❌ 丢失堆栈 log.error("处理失败：" + e.getMessage());

    // ✅ 打印完整堆栈 log.error("处理失败", e);

10. 单元测试覆盖异常场景

确保代码中的异常分支被测试覆盖，尤其是自定义异常和资源关闭逻辑。

@Test
void testTransfer_InsufficientBalance() {
    assertThrows(BusinessException.class, () -> {
        accountService.transfer(from, to, amount);
    });
}

总结：异常处理黄金法则

原则

说明

明确异常类型

Checked / Unchecked 各司其职

尽早抛出

参数校验前置

晚点捕获

只在有能力处理的地方捕获

不吞异常

要么记录，要么抛出

资源自动关闭

使用 try-with-resources

保留原始异常

传递 cause

丰富上下文

异常信息包含关键参数

统一处理

全局异常处理器

不用于流程控制

性能差，可读性差

记录日志要完整

带上堆栈信息

记住：异常是代码的“故障说明书”，而不是“兜底毯子”。 优雅的异常处理，能让你的系统在出错时依然可控、可追溯、可恢复。

avatar
文章
阅读
粉丝