Java方法重写时子类throws异常范围不能大于父类，否则编译失败；原因在于遵循里氏替换原则，防止调用方因未处理新异常而破坏健壮性；可改用RuntimeException、提升父类异常类型或重构为组合/策略模式。
Java中方法重写时，子类throws的异常范围不能大于父类，这是编译器强制要求的规则——子类只能抛出父类声明异常的子集（包括更具体的异常类型，或不抛出异常），不能新增检查型异常（checked exception），也不能扩大异常范围。违反该规则会直接编译失败。
核心原因：违背里氏替换原则
如果子类方法抛出比父类更宽泛或全新的检查型异常，调用方按父类契约编写代码时（只处理父类声明的异常），运行时可能遇到未捕获的新异常，破坏程序健壮性。因此Java在编译期就禁止这种行为。
解决方案一：子类改用运行时异常（RuntimeException）
若子类内部逻辑确实需要抛出父类未声明的异常，且该异常属于“编程错误”或“不可恢复的意外”，可将其包装为非检查型异常：
- 用
throw new RuntimeException(cause)或自定义RuntimeException子类包裹原异常 - 避免在
throws子句中声明新检查型异常 - 例如：父类方法声明
throws IOException，子类内部遇到SQLException，可写成throw new RuntimeException("DB error", sqlEx)
解决方案二：统一向上提升异常类型
在父类方法中提前声明更通用的检查型异常（如Exception），为子类留出扩展空间：
立即学习“Java免费学习笔记（深入）”；
- 父类方法改为
throws Exception（需权衡API清晰度） - 子类可选择抛出
Exception的任意子类，包括自定义异常 - 注意：这会增加调用方的处理负担，不推荐滥用，仅适用于框架级或高度抽象的API
解决方案三：用组合替代继承，或重构异常处理逻辑
当父子类异常语义差异较大，强行继承导致异常设计别扭时，应考虑设计层面调整：
- 将共用逻辑提取为工具类或服务类，由父子类分别调用，各自处理自身异常
- 使用策略模式，让异常处理行为可插拔，而非绑定在继承链上
- 子类内部自行
try-catch消化异常，转为返回错误码、Optional、Result对象等，避免向外抛出
补充说明：运行时异常不受此限制
RuntimeException及其子类（如NullPointerException、IllegalArgumentException）是未检查异常，重写时子类可以自由抛出，无需在throws中声明，也不受父类约束。这是合法且常用的做法。
不复杂但容易忽略——关键在于分清异常性质：检查型异常代表调用方必须应对的外部契约，运行时异常代表内部可修正或应避免的逻辑问题。
