应避免直接 catch Exception,除非顶层兜底;需按异常类型粒度捕获,优先具体异常,禁用 catch Throwable;Spring 中应分类型处理异常,而非统一捕获 Exception。

直接 catch Exception 通常不合适
除非你明确知道当前上下文需要统一兜底处理(比如顶层守护线程、统一 API 错误响应封装),否则用 catch (Exception e) 会掩盖真实问题。它把 RuntimeException 和受检异常一并吞掉,导致空指针、数组越界、类型转换失败等本该暴露的编程错误被静默吞没或误判为业务异常。
Exception vs Throwable vs 具体异常类型的选择依据
Java 异常体系里,Throwable 是根类,分 Error(JVM 级故障,如 OutOfMemoryError)和 Exception;而 Exception 又分受检(IOException)、非受检(RuntimeException 及其子类)。捕获粒度应按「能否恢复 + 是否可控」来判断:
- 能预判且可恢复的场景,捕获具体异常:比如读文件失败,单独 catch
FileNotFoundException做默认配置回退 - 资源清理逻辑必须执行,用
try-with-resources或finally,而不是靠 catchException来“顺便”关流 - 绝不要 catch
Throwable—— 它包含OutOfMemoryError这类已使 JVM 不稳定的错误,强行捕获可能让程序卡死或数据错乱 - 若真需兜底,建议只 catch
Exception,并在日志中记录e.getClass().getName(),避免用e.toString()模糊类型信息
Spring Boot 中全局异常处理的常见误用
很多人在 @ControllerAdvice 里写一个 @ExceptionHandler(Exception.class) 方法来统一返回 JSON 错误,这看似整洁,实则破坏了异常语义:
- 把
NullPointerException和HttpClientErrorException都返回 500,前端无法区分是服务端 bug 还是调用第三方失败 - 未声明的运行时异常本不该由业务层处理,却因这个兜底 handler 被“合法化”,掩盖了空指针源头
- 正确做法是:分别注册
@ExceptionHandler(ValidationException.class)、@ExceptionHandler(HttpClientErrorException.class)等,再加一个最小范围的@ExceptionHandler(RuntimeException.class)用于记录未预期的运行时错误,并主动抛出new IllegalStateException("unhandled runtime exception", e)
IDE 和静态检查能帮上忙的地方
IntelliJ 默认会警告 catch (Exception e),Eclipse 也可通过 Preferences > Java > Compiler > Errors/Warnings 启用 “Unhandled exception type” 检查。更重要的是启用以下两项:
立即学习“Java免费学习笔记(深入)”;
- 把
catch (Exception e)设为 Warning 或 Error(路径:Settings > Editor > Inspections > Java > General > Too broad catch) - 开启
Unchecked exceptions提示:当方法抛出RuntimeException子类但未在文档或注解中标明时,给出提示 - 使用
lombok的@SneakyThrows要格外小心——它只是把受检异常转成运行时异常绕过编译检查,不代表你能忽略 IO 或 SQL 异常的真实处理逻辑
public void processFile(String path) {
try (FileInputStream fis = new FileInputStream(path)) {
// ...
} catch (FileNotFoundException e) {
log.warn("Config file missing, using defaults", e);
loadDefaults();
} catch (IOException e) {
throw new UncheckedIOException("Failed to read config", e);
}
// 不写 catch (Exception e)
}
真正难的不是写 try-catch,而是判断哪一层该暴露异常、哪一层该转换异常、哪一层根本不该出现异常。粒度太粗,等于放弃诊断线索;粒度太细,又容易陷入“每个方法都 throws 十个异常”的泥潭。关键在边界——DAO 层暴露数据异常,Service 层转为业务异常,Controller 层决定是否透出给前端。










