throws是Java中声明受检异常的强制语法，仅对继承Exception而非RuntimeException的异常（如IOException、SQLException）生效，用于明确告知调用者需处理异常，而非逃避责任。
throws 是方法的“异常免责声明”
它不处理异常，只向调用者明确告知：“我这个方法可能会抛出 IOException、SQLException 这类编译时异常，你得自己接住，否则编译直接报错”。这不是可选项，是 Java 编译器强制的契约——没 try-catch，就必写 throws。
哪些异常必须用 throws 声明？
只对**受检异常（checked exceptions）** 强制要求，也就是继承自 Exception 但**不是** RuntimeException 子类的那些：
-
IOException（文件读写、网络请求失败） -
SQLException（数据库操作出错） -
ClassNotFoundException（反射加载类失败） - 你自己写的
class ConfigLoadException extends Exception
而 NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException 这些运行时异常，编译器不管，写了 throws 也不报错，但一般不写——因为它们该靠逻辑预防，不是靠声明甩锅。
throws 写错或滥用的典型坑
新手常掉进这几个坑里：
- 写
throws Exception：太宽泛，调用方无法区分是 IO 问题还是配置问题，失去异常语义；应精确到具体子类，比如throws IOException, SQLException - 私有方法也盲目 throws：比如
private void parseJson() throws JsonParseException，其实内部完全能try-catch+ 返回默认值或打日志，没必要把异常推给本不该关心它的调用者 - 重写方法时扩大异常范围：父类方法声明
throws IOException，子类重写时不能加throws IOException, SQLException，否则破坏多态契约；最多缩小（如只抛FileNotFoundException）或不抛 - 忘了资源清理：声明了
throws IOException，但没用try-with-resources，导致FileInputStream泄漏——throws不等于“放心不管”，该关的流还得关
实际协作中 throws 怎么用才合理？
在分层架构里，throws 是异常传递的“交接点”，不是终点：
- DAO 层：通常直接
throws SQLException或IOException，因为它只管和数据库/文件打交道，不决定怎么提示用户
- Service 层：根据业务规则判断——能重试的（如临时网络抖动）就捕获并重试；需转换语义的（如把
SQLException转成OrderCreationFailedException）就throw new OrderCreationFailedException("库存扣减失败", e)；真正无法兜底的，再throws向上交 - Controller 层：统一用
@ExceptionHandler捕获所有声明的异常，转成 HTTP 状态码和 JSON 错误响应，绝不让原始异常堆栈暴露给前端
最关键的一点：throws 的价值不在“抛”，而在“说清”。一个方法签名里出现的每个异常类型，都应该能在 Javadoc 里找到对应触发条件说明——比如 “throws UserNotFoundException 当数据库未查到匹配的 userId 时抛出”。没文档的 throws，等于埋雷。
