throws必须声明在方法签名末尾，且仅对受检异常强制要求；runtimeexception及其子类无需声明；子类重写时不能扩大异常范围；main中应捕获而非盲目throws；接口声明的throws约束所有实现类。
throws 必须声明在方法签名末尾，且只对受检异常强制要求
Java 中 throws 不是可选修饰，而是编译器强制的契约：如果方法体内调用了可能抛出受检异常（checked exception）的代码，又没用 try-catch 处理，就必须在方法声明后加上 throws 列出该异常类型，否则编译失败。
常见误操作是试图对 RuntimeException 及其子类（比如 NullPointerException、IllegalArgumentException）加 throws —— 编译器不拦你，但毫无意义，因为调用方无需强制处理。
-
IOException、SQLException、ClassNotFoundException这类必须显式声明或捕获 - 一个方法可以
throws多个异常，用逗号分隔：throws IOException, SQLException - 子类重写父类方法时，
throws的异常类型不能比父类更宽泛（比如父类声明throws IOException，子类只能throws IOException或其子类，不能加SQLException）
不要在 main 方法里无意义地 throws，除非你真打算让 JVM 退出并打印堆栈
很多初学者在 main 方法末尾写 throws Exception，以为“这样就不用管异常了”。确实能过编译，但实际效果是：一旦异常发生，JVM 直接终止程序，并输出完整堆栈——这对用户不友好，对调试也不可控。
真正合理的做法是，在 main 中做兜底捕获，至少给出可读提示：
public static void main(String[] args) {
try {
readFile("config.txt");
} catch (IOException e) {
System.err.println("配置文件读取失败：" + e.getMessage());
System.exit(1);
}
}
只有当明确希望把异常交给启动容器（如 Servlet 容器）或上层框架统一处理时，才考虑在入口方法中 throws。
throws 和 throw 混用时，别漏掉底层异常的原始信息
当你在方法中捕获一个异常，再用 throw 主动抛出另一个异常（比如封装成业务异常），又想保留原始异常上下文，必须用带 cause 参数的构造函数，而不是简单写 throw new BusinessException("xxx")。
- 错误写法：
throw new BusinessException("文件解析失败")→ 原始ParseException丢失 - 正确写法：
throw new BusinessException("文件解析失败", e)，前提是构造函数支持Throwable cause - 如果自定义异常没提供 cause 构造器，记得在类定义中补上：
public BusinessException(String msg, Throwable cause) { super(msg, cause); }
接口方法声明 throws 后，所有实现类都必须遵守这个契约
接口里的 throws 是 API 的一部分。例如定义 public interface DataLoader { void load() throws IOException; }，那么任何实现类的 load() 方法，要么自己处理 IOException，要么继续 throws IOException（或其子类）。
这点容易被忽略：有人在实现类里写了 try-catch 吞掉异常，方法签名却没删掉 throws，编译器会报错“throws 声明未使用”；反过来，如果接口没声明，实现类也不能擅自加 throws 受检异常。
真实项目中，过度在接口层暴露底层异常（比如把 SQLException 暴露给 service 层）会导致耦合变重。更稳妥的做法是接口只声明领域级异常（如 DataLoadException），由实现类完成转换。
throws 的关键，不是让它“消失”，而是清楚每一层谁该负责捕获、谁该继续上抛、谁该转换封装——尤其是跨模块边界的异常传递，稍不注意就会让调用方陷入“不知道该 catch 什么”的困境。
