throws只声明编译期异常（Exception子类但非RuntimeException子类），如IOException；运行时异常如NullPointerException声明即报错；语法位于方法签名末尾，多异常用逗号分隔；调用方须捕获或继续上抛；构造函数也可throws，影响实例化。
throws 声明的是「编译期异常」，不是所有异常都得写
Java 中 throws 只对 Exception 及其子类（但不包括 RuntimeException 及其子类）生效。换句话说，你写 throws NullPointerException 编译器会直接报错——因为它属于运行时异常，系统不强制声明。
常见误操作是看到某个方法可能抛出异常，就一股脑把所有异常类型都往 throws 后面加，结果发现编译不过。其实只需关注那些继承自 Exception 但不继承自 RuntimeException 的类型，比如：
IOExceptionSQLExceptionClassNotFoundException-
ParseException（来自java.text）
这些才需要显式声明；而 IllegalArgumentException、ArrayIndexOutOfBoundsException 这类，写了反而编译失败。
throws 写在方法签名末尾，多个异常用逗号分隔
语法位置很固定：必须紧跟在参数列表右括号之后、方法体左大括号之前。多个异常之间用英文逗号分隔，不能换行，也不能加 and 或 or。
立即学习“Java免费学习笔记（深入）”；
public void readFile(String path) throws IOException, SQLException {
// 方法体
}
注意：throws 后面的异常顺序无关紧要，但建议按字母序或按实际抛出概率从高到低排列，方便阅读。另外，如果子类方法重写父类方法，它声明的异常不能比父类更宽泛——比如父类声明 throws IOException，子类就不能写 throws Exception，否则编译报错。
声明了 throws 不等于必须 try-catch，调用方也要处理
throws 是把异常责任「向上传递」，不是解决异常。只要方法 A 声明了 throws IOException，那么任何调用 A 的方法 B，就必须做以下二者之一：
- 用
try-catch捕获并处理IOException - 在 B 的方法签名里也加上
throws IOException（继续上抛）
没做任一选择，编译直接失败。这个机制强制开发者面对 I/O、数据库等易出错环节，而不是让异常静默吞掉。
典型反例：
public void saveToFile() throws IOException {
FileWriter fw = new FileWriter("data.txt");
fw.write("hello");
}
这段代码虽然声明了 throws IOException，但 FileWriter 构造本身也可能抛 IOException（比如路径不可写），而这里没做任何处理——声明只是“告知”，不提供兜底。
容易忽略的细节：构造函数也能 throws，且影响实例化
类的构造函数可以像普通方法一样使用 throws，比如：
public class ConfigLoader {
public ConfigLoader(String path) throws IOException {
Files.readString(Paths.get(path)); // 可能抛 IOException
}
}
这意味着：如果某段代码执行 new ConfigLoader("missing.conf")，就必须包裹在 try-catch 里，或者所在方法也声明 throws IOException。这点常被忽略，尤其在 Spring 等框架自动实例化 Bean 时——若构造函数抛出未声明的编译期异常，会导致上下文启动失败，错误堆栈里可能只显示 BeanCreationException，真正根因藏在 cause 里。
更隐蔽的问题是：如果一个类有多个构造函数，只有部分声明了 throws，那使用者必须小心选对那个「安全」的构造方式，否则编译过不了。
