重写方法不能抛出比父类更宽的检查异常
Java 编译器会直接拒绝这种写法：Override 方法如果声明了比父类方法更宽的 throws 类型（比如父类抛 IOException，子类抛 Exception），就会报错 error: overridden method does not throw ... 或更常见的 error: unreported exception ... must be caught or declared to be thrown。这不是 JVM 运行时限制，是编译期契约——子类不能让调用方突然面对更多未预期的检查异常。
三种合法解法及适用场景
核心原则：保持“异常契约”不扩大。实际中只有三条路可走：
- 把子类方法的
throws改成和父类完全一致，或更窄（如只抛FileNotFoundException） - 在子类方法体内用
try-catch捕获更广的异常，转而抛出父类允许的异常类型（或其子类） - 把原方法改成抛运行时异常（
RuntimeException及其子类），因为它们不参与编译检查 —— 但需确认业务逻辑是否真能容忍“不强制处理”
例如父类有 void read() throws IOException，子类想处理网络超时（SocketTimeoutException，是 IOException 子类）没问题；但若想额外抛 SQLException，就必须捕获后包装成 IOException 再抛，或改用 RuntimeException。
为什么不能用 throws Exception 完事
表面看加个 throws Exception 最省事，但会破坏继承契约，导致所有上游调用方代码失效——原来只捕获 IOException 的地方现在必须处理 Exception，甚至可能漏掉新异常。IDE 和编译器会立刻标红，不是风格问题，是类型系统在拦你。
立即学习“Java免费学习笔记（深入）”；
更隐蔽的坑是：如果父类方法本身没声明 throws，子类就完全不能加任何检查异常，连 IOException 都不行。此时唯一合规做法是内部消化（catch 后转成日志、默认值或 RuntimeException）。
Runtime 异常的包装技巧与风险
当必须暴露新异常类型又不想改父类签名时，常见做法是用 RuntimeException 包装：
throw new RuntimeException("DB connection failed", e);
但要注意两点：
- 原始异常
e必须作为 cause 传入构造函数，否则堆栈丢失，排查困难 - 不要滥用——如果上层业务逻辑本就需要区分数据库失败和文件读取失败，硬塞进
RuntimeException会让错误处理退化成instanceof判断，反而更难维护
真正该被忽略的，是那些程序无法恢复、调用方也不该重试的错误（如配置缺失、NPE）。而 IO、SQL 这类典型检查异常，往往意味着需要重试、降级或明确提示用户，强行转成运行时异常，等于把责任推给调用方却不给接口提示。
