Java异常处理：不同异常不同应对方法

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《Java异常处理策略：不同异常不同处理方式》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

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

按异常类型分层捕获，别用一个 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 里吞掉异常或覆盖原异常

典型反模式：

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，而是判断哪一层该终止传播、哪一层该转换语义、哪一层该静默消化。多数线上问题，根源不在没捕获，而在捕获后做了错误的决策。

今天关于《Java异常处理：不同异常不同应对方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！