捕获 runtimeexception 通常是错误的，因其反映程序逻辑缺陷而非外部条件；应提前校验而非掩盖，避免静默忽略、finally 覆盖异常、宽泛捕获 exception/throwable，异步异常需显式处理。
捕获 RuntimeException 通常是个错误决定
除非你明确知道要恢复什么状态，否则不要用 try-catch 包住 NullPointerException、IllegalArgumentException 或 ArrayIndexOutOfBoundsException。这类异常反映的是程序逻辑缺陷，不是外部可变条件（比如文件不存在、网络超时）。掩盖它们只会让 bug 潜伏得更深，调试时更难定位源头。
常见错误现象：
try {
processUser(user.getName().trim());
} catch (NullPointerException e) {
log.warn("user or name is null, skip", e);
return;
}这行代码看似“健壮”，实则把 user 本该非空的契约破坏了——你应该在入口校验 user != null，而不是等 NPE 再吞掉。
- 正确做法是提前防御：用
Objects.requireNonNull()或断言暴露问题 - 若真需兜底（如插件系统），应记录完整上下文（哪个插件、哪行调用、入参快照），而非静默忽略
- JVM 在抛出
RuntimeException时不会强制你声明，但这不等于它可被随意捕获
在 finally 块里再抛异常会覆盖原始异常
当 try 块抛出异常，而 finally 块又抛出另一个异常时，原始异常会被彻底丢弃——这是 Java 的明确语义，不是 bug。很多日志框架或资源关闭逻辑没注意这点，导致关键错误信息丢失。
示例：
try {
throw new SQLException("DB connection failed");
} finally {
conn.close(); // 可能抛 IOException
}最终栈轨迹只显示 IOException，SQLException 彻底消失。
- Java 7+ 推荐用 try-with-resources，它自动抑制次要异常并保留主异常
- 手动写
finally时，所有可能抛异常的操作必须用嵌套try-catch处理，且不能向上抛 - 尤其注意
close()方法本身是否声明了受检异常——不同 SDK 实现有差异
捕获 Exception 或 Throwable 几乎总是过度宽泛
写 catch (Exception e) 看似省事，但会一并捕获 OutOfMemoryError、StackOverflowError 这类 JVM 级别故障。它们无法被业务逻辑“处理”，强行捕获反而干扰 JVM 的崩溃保护机制。
典型误用场景：
try {
doHeavyCalculation();
} catch (Exception e) { // 错！连 ThreadDeath 都被包进来了
fallbackToCache();
}
- 优先捕获具体异常类型，比如
IOException、ParseException - 如果必须兜底，至少排除
Error子类：if (e instanceof Error) throw (Error) e; -
Thread.currentThread().getUncaughtExceptionHandler()才是处理未捕获异常的正道，不是靠顶层catch (Exception)
异步任务中未显式处理异常等于丢弃异常
用 CompletableFuture.runAsync() 或线程池提交 Runnable 时，如果任务内部抛出未捕获异常，它不会传播到调用方，也不会打印日志——默认被 ForkJoinPool 吞掉。这和同步调用的异常传播行为完全不同。
立即学习“Java免费学习笔记（深入）”；
验证方式：
CompletableFuture.runAsync(() -> {
throw new RuntimeException("this will vanish");
});控制台不会输出任何内容。
- 必须显式处理：用
whenComplete((r, e) -> { if (e != null) log.error("", e); }) - 或统一设置默认异常处理器：
ForkJoinPool.commonPool().setUncaughtExceptionHandler(...) - Spring 中使用
@Async时，异常同样不会抛给调用方，需配合AsyncUncaughtExceptionHandler
