throw用于方法体内主动抛出异常对象，后接Throwable实例；检查型异常需throws声明或try-catch处理，运行时异常可直接抛出。
throw 用于在方法体内主动抛出异常对象
当你需要在代码执行过程中手动触发一个异常，比如校验失败、状态非法时，就用 throw。它后面必须跟一个 Throwable 或其子类的实例，不能是类名或字符串。
常见错误现象：throw new Exception(); 编译不通过（未处理检查型异常）；throw "error"; 直接报错（类型不匹配）。
-
throw只能抛出一个异常对象，不能抛出多个 - 如果抛出的是检查型异常（如
IOException），当前方法必须用throws声明，或用try-catch捕获 - 运行时异常（如
IllegalArgumentException）可直接throw，无需声明
public void setAge(int age) {
if (age < 0) {
throw new IllegalArgumentException("年龄不能为负数");
}
this.age = age;
}
throws 用于在方法签名中声明可能抛出的检查型异常
throws 不抛异常，只是“提前报备”——告诉调用者：“我这个方法可能会甩出这些异常，你得负责处理”。它只对检查型异常（Exception 及其子类，但不包括 RuntimeException）有强制约束力。
使用场景：文件读写、网络请求、反射调用等底层操作，通常由 JDK API 抛出 IOException、SQLException 等。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 一个方法可以
throws多个异常，用逗号分隔：throws IOException, SQLException -
throws不影响运行时行为，只是编译期契约；运行时是否真抛，取决于实际执行路径 - 子类重写父类方法时，
throws的异常类型不能比父类更宽泛（只能相同或更具体）
public String readFile(String path) throws IOException {
return Files.readString(Paths.get(path));
}
throw 和 throws 混用是常态，不是错误
绝大多数真实场景里，二者配合使用：方法内部用 throw 触发异常，方法签名用 throws 向外声明。这不是设计缺陷，而是 Java 强制检查型异常处理机制的体现。
容易踩的坑：throws Exception 过度宽泛，掩盖真实异常类型；或者在已经 catch 住异常后，又无意义地 throw 出去却不记录日志。
- 优先抛出语义明确的异常子类，如
FileNotFoundException而非笼统的IOException - 若在
catch块中重新抛出，建议用throw new XxxException("msg", e)保留原始栈轨迹 - 不要为了编译通过而写
throws Exception，这会让调用方无法针对性处理
运行时异常（RuntimeException）不用 throws 也能 throw
像 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException 这类，继承自 RuntimeException，Java 不强制要求声明或捕获。你可以随时 throw，调用方也完全可以选择忽略。
但这不等于“应该忽略”——过度依赖运行时异常会削弱接口契约，增加排查成本。
- 业务校验逻辑推荐用运行时异常（如
IllegalStateException），避免污染方法签名 - 框架层或跨系统交互，仍建议用检查型异常明确传播风险点
- 自定义异常时，根据是否需要调用方强制处理，决定继承
Exception还是RuntimeException
throws IOException 盲目一路向上扔，却没在关键节点做语义转换或上下文补充。 
