运行时异常不受重写规则限制：子类可自由抛出任意runtimeexception及其子类，因编译器不强制处理；但检查型异常受严格限制，父类声明的checked exception范围子类不可扩大。
可以，完全没问题。
运行时异常不受重写规则限制
Java 对子类重写方法时抛出的 检查型异常（checked exception） 有严格范围限制，但对 RuntimeException 及其所有子类 完全不设限。无论父类方法是否声明 throws、声明了什么异常，子类都可以自由抛出任意 RuntimeException 类型，包括：
- 系统自带的：IllegalArgumentException、NullPointerException、ArithmeticException 等
- 自定义的：比如 extends RuntimeException 的 ValidationFailedException、NetworkTimeoutException
- 甚至比父类已声明的异常更“宽”的 RuntimeException（如父类只抛 IOException，子类额外 throw new RuntimeException("oops")）
为什么允许？设计逻辑很清晰
因为 RuntimeException 是未检查异常，编译器不要求调用方捕获或声明。所以子类加不加、换不换、多抛几个，都不会破坏调用方已有的代码逻辑：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 父类引用调用该方法时，原有 try-catch 块照常工作
- 没写 catch 的地方，异常仍会向上冒泡，行为一致
- 这本质上是 Java 为“编程错误”和“不可恢复意外”预留的安全出口
实际怎么用才合理
虽然技术上自由，但建议保持语义清晰：
- 避免无意义地抛出泛泛的 RuntimeException；优先用具体子类，比如用 IllegalArgumentException 而不是 new RuntimeException("bad arg")
- 如果子类新增的错误场景有业务含义（如“库存不足”），就定义自己的 RuntimeException 子类，便于上层分类处理
- 不要为了绕过检查异常限制，把本该处理的 IOException 包装成 RuntimeException 后随便扔出去——该捕获消化的，还是得在子类内部做
注意别和检查异常搞混
这条自由仅适用于 RuntimeException 体系。如果你试图在 throws 中声明一个更宽的 检查型异常（比如父类 throws IOException，子类 throws Exception），编译器会立刻报错，和 RuntimeException 完全无关。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
