在Java中throw和throws关键字如何使用_Java异常抛出机制解析

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 等。

• 一个方法可以 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 盲目一路向上扔，却没在关键节点做语义转换或上下文补充。