构造方法不能吞掉checked异常，必须显式声明throws或转为unchecked异常；推荐用静态工厂方法处理复杂初始化异常，并确保final字段初始化语义正确。
构造方法里不能用 try-catch 吞掉 checked 异常
Java 构造方法本身不支持声明 throws Exception，但可以声明 throws 具体的 checked 异常类型。如果内部调用了可能抛出 IOException 或 SQLException 的代码，你不能简单用 try-catch 把它“吃掉”然后静默返回——这会让调用方完全不知道对象创建失败了，后续 null 或半初始化对象极易引发 NullPointerException 或状态不一致。
- 正确做法是：在构造方法签名中显式声明
throws IOException，把异常责任上抛 - 错误写法示例：
catch (IOException e) { /* 什么也不做 */ }—— 这等于主动埋雷 - 如果必须处理，应转为 unchecked 异常，如
throw new RuntimeException("init failed", e)，但需确保调用方能接受这种语义
使用静态工厂方法替代构造方法处理复杂异常
当对象初始化逻辑涉及 I/O、网络或数据库操作，且异常类型多样、恢复策略不一时，直接用构造方法会迫使所有调用点都处理一堆 checked 异常。更可控的方式是改用静态工厂方法。
- 工厂方法可自由声明
throws IOException, SQLException，也可统一包装为自定义异常，比如throw new DataLoadException("failed to load config", e) - 还能做轻量预检：先验证参数/资源可用性，再决定是否进入构造流程，避免构造一半失败后留下难以清理的中间状态
- 示例签名：
public static DatabaseConnection create(String url) throws ConfigLoadException
注意构造函数链中异常传播的断点问题
子类构造方法隐式或显式调用 super(...) 时，若父类构造方法声明了异常，子类构造方法也必须声明相同或更宽泛的异常类型，否则编译失败。
- 常见报错：
Unhandled exception type XXXException，本质是子类没对父类抛出的 checked 异常做响应 - 不能靠在子类构造里
try-catch父类调用——super()必须是第一行语句，无法包裹 - 解决方案只有两个：要么子类构造也
throws对应异常；要么父类改用 unchecked 异常，但要评估语义合理性
初始化块和 final 字段对异常处理的限制
如果类中有 final 字段，且依赖可能失败的操作来赋值（比如读配置文件），就不能在构造方法外延迟初始化——因为 final 字段必须在构造结束前明确赋值。
立即学习“Java免费学习笔记（深入）”；
- 实例初始化块中抛出 checked 异常？不行，它会被视为构造过程一部分，同样受构造方法异常声明约束
- 可行路径只有：把初始化逻辑提前到静态工厂中完成，再将结果传入私有构造方法；或接受
final字段为null，改用 getter 懒加载（但破坏了不可变性承诺） - 一个典型陷阱：
private final Connection conn = DriverManager.getConnection(url);—— 这行代码实际等价于放在构造方法第一行，SQLException必须被声明或包装
构造方法里的异常从来不是“怎么捕获”的问题，而是“谁该负责、何时暴露、如何表达失败语义”的设计选择。越早把异常决策下沉到接口契约层（比如工厂方法签名），后续维护成本越低。
