throws只能声明检查型异常且必须位于方法签名末尾；位置错误、声明运行时异常或重复父子类异常均导致编译失败；调用方必须捕获或继续上抛，形成显式异常传播链。
throws 只能声明检查型异常，且必须写在方法签名末尾；写错位置、声明运行时异常或重复父子类异常都会直接编译失败。
throws 的位置和语法必须严格匹配
它不是语句，而是方法签名的一部分：必须紧跟在参数列表右括号 ) 后、方法体左大括号 { 前。任何偏移（比如塞进方法体内、放在返回类型前、或者漏掉括号）都会触发编译错误，例如 Syntax error on token "throws", delete this token 或 invalid method declaration; return type required。
正确写法示例：
public void saveToFile(String path) throws IOException, SQLException { ... }
常见误写包括：
- 把
throws当成执行逻辑写在方法体里 - 和
throw混淆（后者是抛出动作，后者是声明承诺） - 在构造函数或 lambda 表达式中误用（它们不支持 throws 声明）
只能声明检查型异常（Checked Exception）
IOException、SQLException、ParseException 这类编译器强制你处理的异常才能出现在 throws 列表里；NullPointerException、IllegalArgumentException、ArithmeticException 等运行时异常（RuntimeException 及其子类）可以声明，但毫无约束力——编译器不会强制调用方处理，也不推荐这么做。
真正起作用的只有检查型异常。声明了 RuntimeException ≠ 能避免抛出，只是多写了行无意义的提示。
典型场景：
- 读文件：必须声明
IOException - 解析 JSON：若用 org.json，可能需声明
JSONException - 数据库操作：常声明
SQLException
多个异常怎么列？父子类不能混着写
多个检查型异常用英文逗号分隔，但要注意继承关系：如果已声明父类异常（如 Exception 或 IOException），就不能再声明它的任意子类（如 FileNotFoundException 或 EOFException），否则编译报错。
❌ 错误写法：void process() throws Exception, FileNotFoundException
✅ 正确做法是只写最具体的异常，或只写父类（但不推荐宽泛声明）：
- 优先列具体异常：
throws FileNotFoundException, SQLException - 避免
throws Exception—— 它掩盖真实问题，让调用方无法针对性处理 - 子类异常必须出现在父类之前（如果真要混用，极少需要）
调用方不处理就会编译失败
这是 throws 最关键的契约性：一旦方法 A 声明了检查型异常，所有直接调用 A 的方法 B 就只有两条路——要么用 try-catch 捕获，要么在自己的签名里也加 throws 继续上抛。没有“忽略”选项。
这意味着异常传播链是显式、可追踪的。容易被忽略的一点是：这个约束对匿名内部类、Lambda 里的方法调用同样生效，但 Lambda 本身不能带 throws 声明，所以常需包装成自定义函数式接口或提前捕获。
实际影响：
- IDE 会标红未处理的调用，强迫你面对异常流
- 过度使用宽泛
throws会导致上层方法签名越来越臃肿 - 接口方法若声明了异常，所有实现类都必须遵守该异常契约
