在Java中如何为不同异常设计不同的处理逻辑_Java异常策略设计说明-java教程-PHP中文网

应按异常类型分层捕获：先业务异常（如AccountNotFoundException），再可重试I/O异常（如IOException），最后RuntimeException；禁用catch(Exception e)；自定义异常需语义明确、带错误码和可重试标识；资源关闭用try-with-resources；@ExceptionHandler须匹配HTTP状态码，避免全兜底。

在java中如何为不同异常设计不同的处理逻辑_java异常策略设计说明

按异常类型分层捕获，别用一个 `catch (Exception e)` 包打天下

Java 异常体系里，RuntimeException 及其子类是 unchecked，其他（如 IOException、SQLException）是 checked。这两类异常的处理意图完全不同：前者多反映程序逻辑缺陷（如 NullPointerException），后者往往对应可恢复的外部故障（如网络超时、文件不存在）。

常见错误是写成这样：

try {
    doSomething();
} catch (Exception e) {
    logger.error("出错了", e);
    throw new ServiceException("操作失败");
}

这会把 IllegalArgumentException 和 SocketTimeoutException 一锅端，掩盖了问题性质。正确做法是显式分层：

先捕获具体业务异常（如 AccountNotFoundException），走定制化响应（HTTP 404 + 提示文案）
再捕获可重试的 I/O 异常（如 IOException），考虑降级或重试逻辑
最后用 catch (RuntimeException e) 拦住未预期的编程错误，记录堆栈并返回 500
避免捕获 Exception 或 Throwable，除非在最外层统一兜底（如 Spring 的 @ControllerAdvice）

自定义异常要带语义，别只是包装 `Exception`

直接继承 Exception 或 RuntimeException 不够——关键是要让调用方能靠类型判断“接下来该做什么”。比如 InsufficientBalanceException 和 InvalidCurrencyException 都属于支付失败，但前端提示、是否允许重试、是否触发告警，都应不同。

实操建议：

异常类名必须表明失败原因和边界（如 PaymentTimeoutException 而非 PaymentException）
构造函数接受原始异常（cause）并保留堆栈，便于排查链路
可加字段（如 errorCode、retryable），但避免在异常里放业务数据（如用户 ID）——这些应通过日志或上下文传递
Spring 项目中，配合 @ResponseStatus 直接绑定 HTTP 状态码，比在 controller 里 if-else 判断更清晰

不要在 `finally` 里吞掉异常或覆盖原异常

典型反模式：

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

Connection conn = null;
try {
    conn = dataSource.getConnection();
    // ... 执行 SQL
} finally {
    if (conn != null) {
        try {
            conn.close(); // 这里抛出 SQLException
        } catch (SQLException e) {
            logger.warn("关闭连接失败", e); // 吞掉！
        }
    }
}

如果 try 块里已抛出 SQLException，finally 中再抛异常会覆盖原始异常，导致根因丢失。

正确做法：

用 try-with-resources（JDK 7+），自动抑制次要异常（addSuppressed）并保留主异常
若必须手动关资源，finally 中的 close 操作也需 try-catch，且不能 throw 或 return
绝不写 catch (Exception e) { /* 什么也不做 */ } —— 至少记一条 warn 日志

Spring 中用 `@ExceptionHandler` 统一收敛，但别让它变成异常黑洞

@ControllerAdvice + @ExceptionHandler 是集中处理的好方式，但容易滑向“全收全转”的陷阱：所有异常都转成 ErrorResponse 并返回 200，掩盖了 HTTP 状态码语义。

要点：

为不同异常类型配不同状态码：@ExceptionHandler(NotFoundException.class) → @ResponseStatus(HttpStatus.NOT_FOUND)
避免在 handler 里重新 throw 新异常（如 throw new RuntimeException("包装一下")），这会让外层兜底逻辑重复处理
慎用 @ExceptionHandler(Exception.class)：它会吃掉你精心设计的细粒度 handler，应放在最末尾，且只做日志和兜底响应
如果异常需要异步通知（如发告警）、或触发补偿事务，别塞进 handler——用事件机制（如 ApplicationEventPublisher）解耦

异常策略最难的不是写多少 catch，而是判断哪一层该终止传播、哪一层该转换语义、哪一层该静默消化。多数线上问题，根源不在没捕获，而在捕获后做了错误的决策。