不建议捕获 throwable 是因为它会拦截系统级错误（如 outofmemoryerror）和致命终止信号（如 threaddeath），导致 jvm 无法正确终止或恢复，从而掩盖严重故障。正确的做法是仅捕获 exception 及其子类，或者在必须处理所有异常时使用 catch-all 但需明确区分并重新抛出非 runtimeexception 的情况。
为什么捕获 Throwable 会破坏 JVM 的终止机制？
捕获 Throwable 会阻止 Thread.stop() 触发的 ThreadDeath 异常向上传播，导致线程无法正常退出。当代码中显式捕获了 Throwable 时，JVM 发出的终止信号会被当作普通异常处理，程序可能继续执行后续逻辑，造成资源泄漏或状态不一致。
public class ThreadStopDemo {
public static void main(String[] args) throws InterruptedException {
Thread thread = new Thread(() -> {
try {
while (true) {
System.out.println("Running...");
Thread.sleep(1000);
}
} catch (Throwable t) {
// 这里捕获了 ThreadDeath，导致线程不会真正停止
System.out.println("Caught: " + t.getClass().getName());
}
});
thread.start();
Thread.sleep(2000);
thread.stop(); // 触发 ThreadDeath
thread.join();
System.out.println("Main finished");
}
}
运行上述代码，控制台会持续打印 "Running..." 和 "Caught: java.lang.ThreadDeath"，主线程的 join() 将永远阻塞，因为子线程并未按预期终止。这证明了捕获 Throwable 会干扰线程的生命周期管理。
立即学习“Java免费学习笔记（深入）”；
捕获 Throwable 如何掩盖内存溢出等致命错误？
捕获 Throwable 会吞掉 OutOfMemoryError 和 StackOverflowError 等 Error 子类，使程序在资源耗尽后继续运行，产生不可预测的数据损坏或逻辑错误。开发者应优先捕获 Exception，仅在极少数需要记录所有堆栈信息的场景下才考虑捕获 Throwable，且必须确保重新抛出非运行时异常或致命错误。
public class MemoryLeakDemo {
public static void main(String[] args) {
try {
simulateOOM();
} catch (Throwable t) {
// 错误地被捕获，程序继续执行
System.out.println("Caught OOM: " + t.getMessage());
continueProcessing(); // 尝试继续处理，可能导致更多错误
}
}
private static void simulateOOM() {
List<byte[]> list = new ArrayList<>();
while (true) {
list.add(new byte[1024 * 1024]); // 每MB分配一次
}
}
private static void continueProcessing() {
System.out.println("Continuing after OOM - Data may be corrupted");
}
}
该示例展示了当 simulateOOM() 抛出 OutOfMemoryError 时，被 catch (Throwable) 捕获后，程序仍调用 continueProcessing()。此时堆内存已耗尽，后续操作极可能再次失败或产生脏数据，而开发者却误以为程序正常运行。这种隐蔽性比直接崩溃更危险。
在什么具体条件下捕获 Throwable 是合理的？
只有在顶层全局异常处理器中，为了记录完整的堆栈跟踪信息以便调试，才建议捕获 Throwable，并且必须在记录日志后根据类型决定是否重新抛出。例如，在 Web 应用的 Filter 或 Spring 的 @ControllerAdvice 中，可以捕获 Throwable 以统一记录错误，但需确保对 Error 类进行特殊处理，避免静默失败。
public class GlobalExceptionHandler {
@ExceptionHandler(Throwable.class)
public ResponseEntity<String> handleAllExceptions(Throwable ex) {
// 记录完整堆栈
Logger.getLogger(GlobalExceptionHandler.class.getName())
.log(Level.SEVERE, "Unhandled exception", ex);
// 对于致命错误，不应返回正常HTTP响应，而应让JVM处理
if (ex instanceof Error) {
throw (Error) ex; // 重新抛出，允许JVM终止
}
return ResponseEntity.status(500).body("Internal Server Error");
}
}
在此场景中，handleAllExceptions 方法捕获了所有异常，包括 Error。关键逻辑在于判断 ex instanceof Error，如果是，则立即重新抛出，交由 JVM 默认处理机制终止进程；如果不是，则视为业务异常，返回 HTTP 500 响应。这种做法既保证了日志完整性，又避免了掩盖致命错误。
