构造器抛异常时对象不存在；Java规范要求未完成构造的对象不会被引用，堆内存由GC回收，不留下半初始化实例，且需在finally或try-with-resources中释放已获取资源。
构造器本身不创建对象，只负责初始化；一旦初始化失败抛出异常，JVM会立即中止构造流程，对象实例不会被创建，内存也会被回收。这意味着——异常不是“可以忽略的错误”，而是“构造未完成”的明确信号。
构造器里抛异常，对象到底存不存在？
答案是：不存在。Java规范明确规定，若构造器执行过程中抛出未被捕获的异常，该对象的引用永远不会被赋值，堆中分配的内存会被GC视为“未完成对象”而丢弃。哪怕构造器已执行了前90%的代码，只要最后一步抛异常，整个实例就等于没诞生。
- 调用方拿到的只能是null（如果声明为局部变量但未赋值）或未定义状态（如字段未初始化）
- 不会留下半初始化的“残缺对象”，这是Java构造机制的安全保障
- 因此无需手动清理资源——但若构造器中已打开文件、连接数据库等，需在finally块或try-with-resources中确保释放
别在super()之前用this
子类构造器第一行必须是super()或this()调用。此时this引用指向的对象尚未进入子类字段初始化阶段，final字段还没赋值，重写方法可能返回错误结果甚至NPE。
- 编译器会直接报错：Cannot reference 'this' before supertype constructor has been called
- 常见陷阱：把this传给外部工具类、监听器、工厂方法，或在super()前调用依赖this的初始化逻辑
- 解法：将依赖this的操作移到super()之后；或改用静态工厂方法，在对象完全构造后再组装依赖
受检异常 vs 运行时异常：怎么选？
构造器无法返回失败码，只能靠异常传递问题。选择哪种异常，取决于错误性质是否属于“调用方必须应对的契约义务”。
- 用RuntimeException（如IllegalArgumentException、IllegalStateException）：参数校验失败、内部逻辑矛盾、配置明显错误——这类问题应由开发者修复，而非运行时兜底
- 用Checked Exception（如IOException、SQLException）：涉及外部资源（文件、网络、数据库）且失败概率不可忽略——强制调用方决策：重试、降级、还是向上抛
- 避免包装Checked Exception为RuntimeException再抛出，除非你明确放弃调用方的知情权和处理权
静态初始化与构造器异常的叠加风险
类加载阶段的静态块异常（ExceptionInInitializerError）和实例构造异常是两回事。前者会让整个类不可用，后者只影响单个实例。
- 若static块中抛异常，该类后续所有new操作都会直接失败，抛出NoClassDefFoundError
- 构造器异常不会污染类加载状态，但若构造器里误用了未初始化的static字段（比如static Map未在static块中初始化），仍可能引发NPE
- 建议：静态资源用static final + 延迟初始化（Double-Check Locking或Holder模式），避开静态块硬编码风险
