Java中不应滥用catch(Exception e)捕获所有异常，仅限main方法、全局异常处理器、独立线程等顶层“最后防线”场景；日常业务须精准捕获具体异常类型，避免掩盖问题、阻碍调试。
Java里不能也不该用Exception捕获所有异常
直接用 catch (Exception e) 捕获所有异常，看似省事，实则掩盖问题、阻碍调试、违反异常分类设计初衷。Java 的异常体系明确区分 RuntimeException（运行时异常，如 NullPointerException、ArrayIndexOutOfBoundsException）和受检异常（IOException、SQLException等），二者语义和处理策略完全不同。
哪些异常真该用Exception兜底？仅限特定场景
极少数情况允许顶层兜底，比如：
- 应用主入口（如
main方法）防止进程崩溃，但必须记录完整堆栈并退出 - Web 框架的全局异常处理器（如 Spring 的
@ControllerAdvice），用于统一返回友好错误页或 JSON 错误响应 - 独立线程（
Thread.setUncaughtExceptionHandler）避免静默失败
这些场景下兜底是“最后防线”，不是日常编码习惯。日常业务逻辑中，应精准捕获具体异常类型。
常见错误：用Exception代替具体异常处理
典型反模式示例：
立即学习“Java免费学习笔记（深入）”；
try {
Files.readAllBytes(Paths.get("config.txt"));
} catch (Exception e) {
// ❌ 不知道是文件不存在、权限不足，还是磁盘满
System.err.println("读取失败");
}
正确做法是分别处理：
-
IOException：网络/IO 故障，可重试或降级 -
SecurityException：权限问题，需运维介入 -
InvalidPathException：路径格式错误，属编程 bug，不该捕获，应修复输入校验
捕获太宽泛，会导致本该快速暴露的 bug 被吞掉，日志里只剩模糊的“Exception”，排查成本陡增。
如果真要写通用异常处理器，注意三点
以 Spring Boot 全局异常处理为例：
- 优先捕获具体子类（如
@ExceptionHandler(HttpMessageNotReadableException.class)），再用@ExceptionHandler(Exception.class)做保底 - 保底 handler 中必须调用
e.printStackTrace()或通过logger.error("Unexpected error", e)记录完整堆栈 - 绝不能只打印
e.getMessage()—— 会丢失关键上下文（如嵌套异常、行号、调用链）
最易被忽略的一点：JVM 在抛出异常时会填充 stackTrace，但若异常被多次包装（如 new RuntimeException(e)），原始堆栈可能丢失；务必用带 cause 构造函数（new RuntimeException("msg", e)）保留根因。
