在Java中throws关键字如何使用_Java异常声明机制解析

throws关键字用于声明方法可能抛出的检查型异常，不处理异常而交由调用者处理；必须声明Checked Exception，不可声明更宽泛的异常类型，与try-catch分工协作。

throws 关键字不是用来处理异常的，而是把异常声明推给调用者——它不捕获、不解决，只甩锅。

什么时候必须写 throws

当你在方法里调用了可能抛出 Checked Exception（比如 IOException、SQLException）的代码，又不想在当前方法用 try-catch 处理，就必须在方法签名后加 throws 声明。

• RuntimeException 及其子类（如 NullPointerException、ArrayIndexOutOfBoundsException）不用声明，编译器不管
• 一个方法可以声明多个异常，用逗号分隔：throws IOException, SQLException
• 子类重写父类方法时，throws 的异常类型不能比父类更宽（只能相同或更具体）

throws 和 try-catch 不是二选一，而是分工关系

throws 是“我不处理，你来管”；try-catch 是“我接手，我兜底”。两者可共存：内部先局部处理一部分异常，剩下不确定或不归自己管的，再往上抛。

• 常见误用：在已经 catch 了所有可能异常的方法里还写 throws——编译报错，因为没异常可抛了
• 正确做法：只对真正可能逃逸出去的 Checked Exception 声明 throws
• 如果 catch 里又手动 throw new RuntimeException(...)，不需要声明 throws，但调用方得知道这可能是运行时崩

容易被忽略的继承细节

子类方法覆盖父类方法时，throws 列表受严格限制。这是为了保证多态调用安全——上层代码按父类声明做准备，子类不能突然抛出它没防备的异常。

• 父类方法声明 th

  

  rows IOException，子类可以 throws FileNotFoundException（它是 IOException 子类），也可以不写 throws
• 但子类不能 throws SQLException，哪怕逻辑上真发生了——编译直接拒绝
• 若父类没写 throws，子类也不能加（除非抛的是 RuntimeException）

public class FileReader {
    // 正确：声明可能抛出的检查型异常
    public String read(String path) throws IOException {
        return Files.readString(Paths.get(path));
    }

    // 错误示例（编译不过）：父类没 throws，子类却加了
    // @Override
    // public String read(String path) throws IOException { ... }
}

最常踩的坑，是以为写了 throws 就算“处理了异常”，其实只是延迟了责任归属。调用链顶端（比如 main 方法或 Servlet 的 doGet）往往不得不面对这个甩过来的异常——那时才真正需要决定：记录日志？转成用户友好的提示？还是让服务挂掉？