catch(Exception e)会吞掉RuntimeException（如NullPointerException）和受检异常（如IOException），但二者处理意图不同：运行时异常应暴露修复，而非静默忽略；错误吞咽导致空指针后继续执行、堆栈丢失、事务不回滚等严重问题。
catch(Exception e) 会
直接 catch(Exception e) 最大的问题是它会捕获 RuntimeException（比如 NullPointerException、ArrayIndexOutOfBoundsException）以及所有受检异常（IOException、SQLException），但这两类异常的处理意图完全不同。运行时异常通常反映程序逻辑缺陷，理应暴露并修复，而不是静默吞掉。
常见错误现象包括：
- 空指针后程序继续执行，后续抛出更晦涩的
NullPointerException或数据错乱 - 日志只打印了
e.toString()，丢失堆栈，无法定位原始出错位置 - 事务未回滚：在 Spring 中，
catch(Exception e)后没重新抛出，导致本该触发回滚的异常被吃掉
应该 catch 哪些异常：按场景分层处理
异常捕获粒度必须匹配业务语义和控制流意图。不是“能不能捕”，而是“该不该在这里捕”。
推荐做法：
- 明确知道如何恢复的场景，只捕获具体异常类型，例如读文件失败时只捕
FileNotFoundException或IOException，并提供默认值或重试逻辑 - 资源清理（如关闭流、释放锁）用
try-with-resources或finally，不要依赖catch做清理 - 顶层统一异常处理器（如 Spring 的
@ControllerAdvice）可捕Exception，但必须记录完整堆栈、区分错误码，并返回用户友好的提示，而非内部异常信息 - 绝不在循环内写
catch(Exception e) { /* 忽略 */ }—— 这等于主动制造幽灵 Bug
Throwable 和 Exception 的关键区别不能忽略
Exception 是 Throwable 的子类，但 Throwable 还包含 Error（如 OutOfMemoryError、StackOverflowError）。用 catch(Throwable t) 更危险，因为 Error 表示 JVM 严重问题，程序通常已无法可靠继续运行。
典型反例：
try {
doSomething();
} catch (Throwable t) {
log.error("Unexpected error", t);
// 继续执行… 但此时可能内存已耗尽，下一步 new Object() 就又 OOM
}正确做法是让 JVM 在 Error 发生时快速失败（fail-fast），由监控系统捕获并告警，而不是试图“兜住”。
log.error 的参数顺序和堆栈传递常被写错
很多团队写成 log.error("failed to parse json: " + e.getMessage(), e)，这看似有堆栈，实则掩盖了根因 —— e.getMessage() 可能为空或不准确，而日志框架真正依赖的是第二个参数 e 来提取堆栈。更糟的是，有人写成 log.error("error: " + e, e)，导致堆栈被重复打印两次。
安全写法只有这一种：
log.error("failed to parse json", e); // 第一个参数是固定消息，第二个是 Throwable如果需要携带上下文变量，用占位符：
log.error("failed to parse json for user {}", userId, e);Java 异常捕获真正的难点不在语法，而在于每个 catch 块都要回答三个问题：这个异常在此处是否可预期？我有没有能力做有意义的响应？吞掉它会不会让错误更难定位？漏掉任何一个，都可能把小问题拖成线上事故。
