构造方法中不可用try-catch吞掉checked异常，否则对象状态不一致；应抛出异常或改用静态工厂方法，确保资源安全与语义清晰。
构造方法里不能用 try-catch 吞掉 checked 异常
Java 规定：如果构造方法调用的代码抛出 Exception（非 RuntimeException），你必须显式处理——要么在构造方法签名中声明 throws，要么用 try-catch 包住。但问题在于，try-catch 本身不能“吞掉” checked 异常后让构造成功返回；如果资源初始化失败（比如文件读取、网络连接），对象处于不一致状态，强行返回 this 很可能埋下后续 NullPointerException 或逻辑错误。
- 常见错误现象：
IOException在构造中被catch后静默忽略，对象创建看似成功，但内部字段为null或默认值，调用实例方法时才暴雷 - 正确做法是把异常向上抛，由调用方决定重试、降级或终止
- 不要在构造方法里写
throw new RuntimeException(e)包装 checked 异常——这会掩盖异常本质，破坏调用方对错误类型的判断依据
推荐方案：用静态工厂方法替代构造方法
当对象创建过程涉及 I/O、数据库、网络等易失败操作时，直接用构造方法会让 API 不够健壮。静态工厂方法能更自然地表达“可能失败”，也便于后期扩展（比如加缓存、加参数校验、返回子类）。
public class ConfigLoader {
private final Properties props;
// 私有构造，禁止外部直接 new
private ConfigLoader(Properties props) {
this.props = props;
}
// 静态工厂：明确告知调用方可能抛异常
public static ConfigLoader fromFile(String path) throws IOException {
Properties p = new Properties();
try (InputStream is = Files.newInputStream(Paths.get(path))) {
p.load(is);
}
return new ConfigLoader(p);
}
}
- 调用方代码清晰：
ConfigLoader loader = ConfigLoader.fromFile("config.properties");—— 一眼看出这步可能失败 - 构造方法保持精简，只做必要字段赋值，不承担资源加载职责
- 若需统一错误处理，可在工厂方法内将 checked 异常转为自定义 unchecked 异常（如
ConfigLoadException），但必须保留原始cause
如果必须用构造方法抛异常，注意 finalize 和内存泄漏风险
构造方法中途抛异常时，JVM 会释放已分配的内存，但若你在构造中手动注册了回调、启动了线程、打开了文件描述符，而这些动作没有配套的清理逻辑，就可能泄漏资源。
- 典型陷阱：在构造中调用
Runtime.getRuntime().addShutdownHook(...)，但异常导致对象未构建完成，hook 却已注册，后续无法取消 - 打开
Socket或FileChannel后抛异常，未显式close()，依赖 GC 回收不可靠 - 解决思路：所有外部资源获取操作，放在构造末尾；或改用
try-with-resources包裹局部资源，确保即使异常也能释放
常见误用：在构造中调用可被重写的方法
如果父类构造方法中调用了 protected 或 public 方法，而子类重写了它，且该方法又依赖尚未初始化的子类字段，就可能触发 NullPointerException 或返回错误值——这本质上是构造过程中对象状态不一致导致的异常，但堆栈里看不到明显异常源。
立即学习“Java免费学习笔记（深入）”；
- 示例：父类构造中调用
init()，子类重写init()并访问this.config，但此时子类字段还未赋值 - 避免方式：构造方法中只调用
private或final方法；或把初始化逻辑推迟到工厂方法、构建器（Builder）的build()阶段 - 这种异常不会出现在构造签名的
throws列表里，调试时容易误判为“对象创建成功后才出错”
