java Throws 抛出有啥坑

在 Java 里，throws 只是声明“这个方法可能会抛出这些异常”，把处理责任交给调用者。用不好确实有不少坑，下面按常见踩坑点 + 示例 + 建议说。

1️⃣ 只声明不处理，异常一路上抛

坑：

public void read() throws IOException {
    Files.readAllBytes(Path.of("a.txt"));
}

调用者必须继续 throws 或 try-catch，否则编译不过。
如果上层也不管，最后到 main / 线程，直接程序崩溃或日志丢失。

✅ 建议

• 真正“处理不了”才 throws
• 业务异常尽量在合适层捕获、转成自定义异常

2️⃣ throws 范围过大（Exception / Throwable）

坑：

public void doSomething() throws Exception {
}

调用者被迫 catch 所有异常，根本不知道会发生什么。

✅ 建议

• 精确声明具体异常
• 不建议 throws Exception / throws Throwable

3️⃣ 重写方法 throws 不兼容（编译错误）

坑：

class A {
    void f() throws IOException {}
}

class B extends A {
    @Override
    void f() throws Exception {} // ❌ 编译错误
}

✅ 规则

• 子类重写方法 不能抛出比父类更多（更广）的受检异常
• 可以不抛，也可以抛更具体异常

4️⃣ throws 对运行时异常无效

坑：

public void test() throws NullPointerException {
}

NullPointerException 是 RuntimeException
➡ 写了也没约束作用，调用者不 catch 也能编译

✅ 建议

• throws 一般只用于 checked exception
• 运行时异常靠代码健壮性解决

5️⃣ 异常被“吞掉”或丢失原因

坑：

public void f() throws Exception {
    try {
        risky();
    } catch (IOException e) {
        throw new Exception("error"); // 原异常没了
    }
}

✅ 建议

throw new RuntimeException("error", e);

保留 cause，方便排查

6️⃣ 接口设计被 throws 绑死

坑： 接口声明：

interface Service {
    void save() throws IOException;
}

后期实现可能根本不 IO，但接口改不了。

✅ 建议

• 接口层尽量抛 业务异常
• 实现层再转换底层异常

7️⃣ Spring / 框架中 throws 不生效

坑：

@Transactional
public void f() throws RuntimeException {
}

事务是否回滚看是否抛到代理层，不是看 throws

✅ 建议

• 别以为 throws 就等于“会处理”
• 看框架实际异常传播机制

一句话总结

throws 不是“解决异常”，只是“甩锅声明”。
坑主要在这：甩太远、甩太宽、甩错层、甩丢原因。

如果你愿意，可以贴一段你自己的代码，我可以直接帮你指出有哪些 throws 用法有问题。