子类构造方法必须显式处理父类构造方法声明的受检异常，方式仅有两种：在自身签名中继续throws该异常，或通过try-catch捕获处理；但因super()必须为首句，无法直接包裹try-catch，故实际可行方案为抛出异常或依赖父类无异常构造重载。
子类构造方法必须显式处理父类构造方法声明的 throws 受检异常，方式只有两种：在自身构造方法签名中继续 throws 该异常，或在构造方法体内用 try-catch 捕获并处理。
子类构造方法必须调用父类构造方法
Java 规定每个构造方法第一句（隐式或显式）必须是 this(...) 或 super(...)。若父类构造方法声明了受检异常（如 throws IOException），而子类构造方法未捕获，就必须在自己签名中也 throws 相同或其父类异常。
- 不能“绕过”——无法跳过父类构造调用
- 不能“吞掉”——不捕获又不抛出，编译直接报错
-
super(...)调用本身就会触发异常传播检查
两种合法处理方式
假设父类定义：class Parent { Parent() throws IOException { ... } }
子类可选择：
-
继续向上抛出：子类构造方法签名加
throws IOException，且第一行写super() -
在内部捕获：用
try { super(); } catch (IOException e) { /* 处理逻辑 */ }——但注意：super()必须是构造方法第一条语句，所以这种写法非法；正确做法是把可能抛异常的逻辑移到super()之后的普通代码块中，或改用带参构造、委托等设计
⚠️ 关键限制：super() 或 this() 必须是首行，因此无法在它外面套 try-catch。真正可行的捕获方式，是让父类提供不抛异常的构造重载，或把易出错操作移出构造过程（推荐）。
实用建议：避免在构造方法中抛受检异常
构造方法里抛受检异常会显著增加子类继承成本，也违背“构造即成功”的直觉。更健壮的做法：
- 将可能失败的操作（如文件读取、网络连接）移出构造方法，改为独立的
init()或 builder 模式 - 父类提供无异常的默认构造 + 可选的初始化方法
- 必要时用运行时异常（如
IllegalArgumentException）替代受检异常，降低子类负担
编译器只认签名，不看实现细节
即使父类构造方法实际不会抛异常（比如 throws IOException 但内部全是内存操作），只要签名写了，子类就受约束。JVM 不在运行时检查是否真抛，但编译器强制你面对这个契约。
这体现了 Java 受检异常的设计哲学：异常声明是 API 合约的一部分，子类不得擅自削弱。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
