提升Java代码可靠性：5个异常处理最佳实践_java 中捕获异常后的处理-CSDN博客

本文链接：https://blog.csdn.net/dandandeshangni/article/details/148518242

引言

我刚开始接触 Java 后端系统开发那会儿，总觉得异常处理（exception handling）这事儿就是个“得过且过”、“应付了事”的活儿。加个 try-catch，把错误打印出来，然后就接着干别的了。看起来好像也没啥大问题——直到生产环境开始频频出事。

这是我付出惨痛代价后学到的：异常处理不是为了隐藏错误，而是为了明智地管理失败。

让我带你回顾我曾犯过的 5 个真实错误，我做了哪些改变，以及在实际项目中真正管用的方法。

1. 捕获所有异常（然后啥也不干）

在一个微服务里，我们当时调用一个外部 API，像下面这样捕获了 Exception：

try {
    // 调用外部客户端发送数据
    externalClient.sendData(data);
} catch (Exception e) {
    // 沉默是金？
    // 捕获了异常，但什么都没做！
}

这里没有日志、没有告警、也没有重试。从表面上看，这个服务“非常稳定”，从不报错，但实际上什么数据都没发送出去。等我们发现的时候，已经丢了整整三天的生产数据。

✅ 管用的方法：
我们改成了捕获像 HttpClientErrorException 这样的特定异常，清晰地记录失败日志，并且加入了带**指数退避（exponential backoff）**的重试逻辑。

// ...
catch (HttpClientErrorException e) { // 只捕获特定的、可处理的异常
    // 清晰地记录警告日志，包含上下文信息
    logger.warn("向外部 API 发送数据失败，状态码: {}, 响应体: {}",
                e.getStatusCode(), e.getResponseBodyAsString(), e);
    // 在这里可以加入重试逻辑 (例如使用 Spring Retry)
    // 或者将失败的任务放入一个死信队列等待后续处理
}

教训： 只捕获你能处理的异常——并且一定要清晰地记录下来。

2. 捕获并重新抛出异常，却不带任何上下文信息

我曾经像这样包装一个 DAO (数据访问对象) 的调用：

try {
    userRepository.save(user); // 保存用户
} catch (DataAccessException e) {
    // 直接把原始异常重新抛出
    throw e; // 这种做法毫无帮助
}

当这个错误最终出现在日志里时，日志信息里完全看不出是哪个用户、在进行什么操作时、为什么失败了。这给调试带来了极大的困难。

✅ 管用的方法：
我们在重新抛出异常前，加上了有用的上下文信息：

catch (DataAccessException e) {
    // 包装成一个新的、带有清晰上下文信息的异常再抛出
    String errorMessage = "保存 ID 为 " + user.getId() + " 的用户失败";
    logger.error(errorMessage, e); // 记录详细日志
    throw new CustomDataAccessException(errorMessage, e); // 抛出自定义异常，并附上原始异常
}

现在，我们调试问题的速度快多了。
教训： 重新抛出异常时，务必加上有用的上下文。帮帮你未来的自己吧。

3. 对所有错误都用通用的 `RuntimeException`

我曾经在一个 Controller 方法里这么写：

if (user == null) {
    // 直接抛出一个非常通用的运行时异常
    throw new RuntimeException("用户未找到");
}

结果就是，当前端或其他服务调用这个接口时，它们只会收到一个通用的 500 内部服务器错误，而不是一个语义更明确、更恰当的 404 Not Found。这让 API 的调用方无法正确处理错误。

✅ 管用的方法：
我们创建了自定义的业务异常，并使用 @ControllerAdvice 进行全局映射，返回正确的 HTTP 状态码：

// 抛出自定义的、具有明确业务含义的异常
throw new UserNotFoundException("ID 为 " + id + " 的用户未找到");

// ... 在一个全局异常处理类中 ...
@ControllerAdvice
public class GlobalExceptionHandler {

    @ResponseStatus(HttpStatus.NOT_FOUND) // 指定此处理器返回 404 状态码
    @ExceptionHandler(UserNotFoundException.class) // 只处理 UserNotFoundException
    public ResponseEntity<String> handleUserNotFound(UserNotFoundException e) {
        // 返回带有清晰错误信息的 ResponseEntity
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(e.getMessage());
    }
    // ... 其他异常处理器 ...
}

现在，API 的调用方能得到清晰、正确的错误响应，而服务端的日志也同样保持了其应有的作用。
教训： 使用自定义异常来表达业务错误，并通过全局异常处理器来构建整洁、语义明确的 API。

4. 依赖堆栈轨迹 (`printStackTrace()`)，而不记录有用的信息

在一个定时的批处理任务中，我们曾这样捕获和打印异常：

catch (Exception e) {
    // 在生产环境中，这几乎是最低效、最无用的错误处理方式
    e.printStackTrace();
}

当这个任务在凌晨3点失败时，监控系统可能只知道任务失败了，但没有人知道是为什么失败。e.printStackTrace() 的输出通常只会被打印到服务器的标准错误流（stderr）中，在分布式或容器化的生产环境中，这些信息很难被收集和查询，日志系统里几乎找不到有用的线索。

✅ 管用的方法：
我们改用了结构化的日志记录 (使用 SLF4J + Logback/Log4j2 等日志框架)：

// logger 是通过 LoggerFactory.getLogger(...) 创建的 SLF4J Logger 实例
logger.error("批处理任务失败，处理订单 ID: {} 时发生错误。", orderId, e);

这条日志准确地告诉了我们是哪个订单在处理时失败了，以及具体的异常信息（e 会被日志框架格式化为堆栈轨迹）。
教训： 别只打印堆栈轨迹——用清晰的、带上下文细节的日志来记录错误。

5. 忘记清理资源

我们以前是这么读文件的：

// 手动打开和关闭资源
BufferedReader reader = new BufferedReader(new FileReader("data.csv"));
String line = reader.readLine();
// ... 处理 line ...
reader.close();

如果 readLine() 这行代码抛出了一个 IOException，那么 reader.close() 这句代码将永远不会被执行。这导致了文件句柄泄漏，并可能引发后续的文件锁定和内存问题。

✅ 管用的方法：
我们改用了 try-with-resources 语法 (Java 7+):

// 将资源在 try() 括号中声明
try (BufferedReader reader = new BufferedReader(new FileReader("data.csv"))) {
    String line = reader.readLine();
    // ... 处理 line ...
} catch (IOException e) { // 只需要捕获你想处理的异常
    // ... 异常处理 ...
}
// 无论是否发生异常，reader 都会在这里被自动关闭

现在，即使在 try 块中发生异常，reader（以及任何实现了 AutoCloseable 接口的资源）也总能被自动且安全地关闭。
教训： 使用 try-with-resources 来管理文件、流、数据库连接以及任何需要手动关闭的资源。