捕获 Throwable 是一种糟糕的做法吗？

1. 概述

本文将深入探讨在 Java 中 捕获 Throwable 可能带来的问题和风险。

简单来说：✅ 能不用就不用，尤其是生产环境里 catch Throwable 往往是“踩坑”前兆。

2. `Throwable` 类详解

在 Java 中，Throwable 是所有错误和异常的根类（super-class）。它的继承结构如下：

它有两个直接子类：

Error：表示 JVM 层面的严重问题，程序通常无法恢复
Exception：表示程序运行中可能出现的异常，分为 checked（受检） 和 unchecked（非受检） 两种

⚠️ 记住一点：Exception 是我们日常开发中应该关注和处理的；而 Error，按官方文档的说法，是“合理的应用不应该尝试去捕获”的。

3. 可恢复的异常场景

这类问题发生后，程序有能力进行恢复或降级处理。通常由 Exception 的子类表示。

常见例子包括：

❌ FileNotFoundException：文件不存在，属于受检异常，调用方可以提示用户或使用默认路径
❌ AccessControlException：权限不足，属于非受检异常，可跳过操作或记录日志
❌ CapacityException：业务逻辑校验失败，可提示输入错误

Java 文档明确指出：Exception 表示“一个合理的设计良好的应用可能希望捕获的条件”。

4. 不可恢复的严重错误

这类问题一旦发生，JVM 已处于不稳定状态，继续执行可能导致数据损坏或行为不可预测。

典型代表：

⚠️ StackOverflowError：栈溢出，递归太深或无限循环
⚠️ OutOfMemoryError：内存耗尽，堆空间不足或 GC 无法回收

这些都属于 Error 的子类。官方文档说得非常清楚：“合理的应用不应尝试捕获 Error”。

你 catch 了又能怎样？内存都没了，还怎么执行清理逻辑？

5. 可恢复 vs 不可恢复：代码示例

假设我们有一个存储接口，用于向集合中添加唯一 ID：

class StorageAPI {

    public void addIDsToStorage(int capacity, Set<String> storage) throws CapacityException {
        if (capacity < 1) {
            throw new CapacityException("Capacity of less than 1 is not allowed");
        }
        int count = 0;
        while (count < capacity) {
            storage.add(UUID.randomUUID().toString());
            count++;
        }
    }

    // other methods go here ...
}

调用该方法时可能出现以下几种异常：

异常类型	类型	是否可恢复	原因
`CapacityException`	checked Exception	✅ 是	参数校验失败，提示用户即可
`NullPointerException`	unchecked Exception	✅ 是	输入为空，可做空判断或默认处理
`OutOfMemoryError`	Error	❌ 否	JVM 内存枯竭，程序已无法正常运行

关键点：前两者可以处理，最后一个你 catch 了也救不回来。

6. 为什么不应该 catch `Throwable`

假设调用方用了“一锅端”式异常捕获：

public void add(StorageAPI api, int capacity, Set<String> storage) {
    try {
        api.addIDsToStorage(capacity, storage);
    } catch (Throwable throwable) {
        // do something here
    }
}

这就意味着：无论是参数错误还是内存溢出，都被同一个 catch 块处理。

这会带来几个致命问题：

❌ 问题一：违背异常处理原则

异常处理的最佳实践是：**catch 越具体越好**。用 Throwable 相当于写了个“万能 catch”，完全失去了异常分类的意义。

❌ 问题二：掩盖致命错误

你可能在 catch 块里打个日志就继续执行了，但如果是 OutOfMemoryError，JVM 可能已经处于崩溃边缘，继续运行只会让问题更严重。

❌ 问题三：逻辑混乱

要想区分处理，你得手动 instanceof 判断：

catch (Throwable t) {
    if (t instanceof OutOfMemoryError) {
        // 重启？退出？你能做什么？
    } else if (t instanceof CapacityException) {
        // 提示用户重试
    }
    // ... 更多判断
}

这代码写出来自己都看不下去，维护成本极高。

✅ 正确做法：分层捕获

public void add(StorageAPI api, int capacity, Set<String> storage) {
    try {
        api.addIDsToStorage(capacity, storage);
    } catch (CapacityException | NullPointerException e) {
        // 处理业务异常
        System.err.println("Input error: " + e.getMessage());
    } catch (OutOfMemoryError error) {
        // 致命错误，建议直接退出或触发 JVM 重启机制
        System.err.println("JVM is unstable: " + error.getMessage());
        throw error; // 或 System.exit(1)
    }
    // 其他 Error 不处理，交给上层或 JVM
}

简单粗暴但有效：该处理的处理，该放过的放过。

7. 总结

❌ 不要轻易 catch Throwable —— 它会把你带进坑里
✅ 优先捕获具体的 Exception 子类，做到精准处理
⚠️ Error 类型的问题不要试图“恢复”，多数情况下应让 JVM 退出或重启
🛑 如果非要用 catch (Throwable)，务必在日志中记录完整堆栈，并考虑重新抛出或终止进程

示例代码已托管至 GitHub：https://github.com/eugenp/tutorials/tree/master/core-java-modules/core-java-exceptions-2

Persistence

REST

Security