应避免直接 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 层决定是否透出给前端。 
