渲染崩溃恢复（RenderRecovery / RenderFailures）

基本信息

这是一个崩溃后把 GL / Iris / 字体 / HUD 缓存状态全部复位的子系统。存在的理由很直接：Angelica 在一帧里做了大量 GL 状态跟踪（GLSM）、display list 编译（Iris）、字体批处理缓存、HUD 缓存 —— 其中任何一步抛异常，若不复位，1.7.10 的 Minecraft.runGameLoop 不会自动清理，下一帧就会带着脏状态继续跑，故障现场会被掩盖。

resetAfterCrash 的 12 步复位

RenderRecovery.resetAfterCrash()（:24-40）无条件、无 try/catch 顺序执行：

实际是 13 步。

⚠️ 第 11 步是唯一直接赋值私有静态字段的地方：TesrAttribution.currentRenderable = null。该字段是 public（TesrAttribution.java 只有 7 行，字段可见性需要单独确认），这不是通过 setter，而是跨类直接写。若 TesrAttribution 改字段名，这里编译不过；更糟的是若该字段语义从「当前渲染目标」变成别的含义，这里会静默复位错东西。

跨子系统依赖（本条目是耦合度最高的文件之一）

RenderRecovery.java 一共 import 17 个类，其中 3 个来自非 Angelica 包。注意 net.coderbot.iris 是内嵌上游，不是 Angelica 的代码 —— 但这个文件本身是 Angelica 原创的复位逻辑。

resetFont：唯一的抽象点

// :43-45
private static void resetFont(FontRenderer fr) {
    if (fr instanceof FontRendererAccessor a && a.angelica$getBatcher() != null) a.angelica$getBatcher().resetAfterCrash();
}

用 instanceof + mixin accessor 拿批处理器，两重 null 检查：

1. fr 是不是 Angelica 增强过的 FontRenderer（即 mixin 是否生效）
2. angelica$getBatcher() 是否为 null（批处理器是否已创建）

resetAfterCrash() 是 FontRenderer 批处理器上的方法，定义在 mixin 侧 —— 见 Angelica mixin 分组。

⚠️ 两个检查都是「失败就静默跳过」。若 mixin 因其它 mod 冲突未生效，resetFont 什么都不做也不会报错，字体缓存的脏状态会留到下次 —— 这正是最难排查的一类故障。

崩溃自测（crashTest）

RenderRecovery 内含一对故意制造崩溃的方法，用于验证复位路径本身是否有效：

// :47-50
public static void armCrashTest()  { crashTestArmed = true; }

// :52-58
public static void throwIfCrashTestArmed() {
    if (crashTestArmed) {
        crashTestArmed = false;
        throw new IllegalStateException("angelica crashtest");
    }
}

armCrashTest / throwIfCrashTestArmed 都是 public static，但 crashTestArmed 字段本身是私有的 —— 外部只能通过这两个方法操作。

抛出点在 MixinTileEntityRendererDispatcher（shaders mixin 组），也就是说崩溃发生在方块实体渲染派发时，而不是任意位置。这是为了让复位路径覆盖到 TESR 相关的脏状态（步骤 9-11）。

RenderFailures：异常合并三件套

22 行，三个静态方法，全部是 try-with-resources / lambda 场景下的辅助工具：

两个必须注意的实现细节

1. suppress 的 self-suppress 防护（:7）。failure != cleanup 这个判断防止 t.addSuppressed(t) —— JDK 的 addSuppressed 会直接抛 IllegalArgumentException("Self-suppression not permitted")，在异常清理路径上再抛一次会把原始异常吃掉。这是必需的防御，不是冗余判断。RenderFailuresTest.java:17 专门测了这一点。

2. rethrow 的无检查转换（:11）。throw (T) failure 里 T 是方法类型参数，由调用点推断。RenderFailuresTest.java:19 用 assertThrows(Exception.class, () -> RenderFailures.rethrow(primary)) 让 T 推断为 Exception。这依赖调用点的捕获类型；如果调用方只 catch 了具体异常而 failure 实际是别的类型，异常会直接逃逸出该 catch 块。这是有意的 sneaky-throw 模式，不是漏洞，但审计时容易误判。

3. rethrowWrapped 不是 rethrow 的替代品 —— 前者会把受检异常包成 RuntimeException，后者原样抛（靠类型擦除骗过编译器）。两者的使用场景不同，不要混用。

已知问题 / 风险

1. resetAfterCrash 无异常保护。13 步任一步抛异常，后续 12 步全部跳过。第 2 步（destroyPipeline）和第 8 步（bindFramebuffer）最可能抛 —— 前者依赖 Iris 管线处于可销毁状态，后者依赖 GL 上下文仍然有效。没有 finally 链，没有聚合异常（尽管同包的 RenderFailures.suppress 正是干这个的，这里却没用上）。这是最值得指出的结构性缺陷。
2. resetAfterCrash 依赖 GL 上下文存活。它自己调用 glBindFramebuffer / GLStateManager.reset()，这些在 GL 上下文已丢失（如窗口被系统回收）时会二次失败。
3. crashTestArmed 非 volatile。armCrashTest() 在命令线程，throwIfCrashTestArmed() 在渲染线程。private static boolean 无内存屏障 —— 严格按 JMM，渲染线程不保证能看到命令线程写入的 true。实践中单线程游戏循环 + 命令在主线程执行使其能工作，但这是未同步的跨线程可见性依赖。同理 true → false 的清除也不保证对其它线程可见。
4. resetFont 双重静默跳过（见上），mixin 失效时无任何诊断输出。
5. RenderFailures 本身没有缺陷，但 RenderRecovery.resetAfterCrash 没用它（见问题 1）。对比 ParticleInstancer.endLayer()（particles/ParticleInstancer.java:208、:216、:224、:237）与 TesrBatchRenderer（:594、:598）—— 这两处都正确地用 suppress 聚合了 finally 里的多个异常，是仓库内 RenderFailures 的正确用法样板。resetAfterCrash 缺同样的聚合。

RenderFailures 的生产调用点（集合运算，20 处）

⚠️ AngelicaBufferSource 的归属需要留意：它的包路径是内嵌上游 net.coderbot.batchedentityrendering，但类名是 AngelicaBufferSource。包在 vendored 命名空间、类名带 mod 前缀 —— 这种「上游包内的 mod 私有类」是内嵌改写的常见手法，但也意味着它可能只被本仓 mixin 注入调用，无法从包名判断生命周期。

⚠️ RenderFailures 唯一未被使用的是 rethrowWrapped 的受检异常包装语义（只有 ParticleInstancer.java:237 一处用），其余全部用 rethrow 或 suppress。

相关条目

• AngelicaCommand - armCrashTest() 的触发点
• HUDCaching - 复位步骤 7
• TESR 实例化管线 - 复位步骤 9-11
• Subprojects（内嵌子项目） - GLSM 所在
• Iris（内嵌） - 复位步骤 2、12 的来源
• Compat Runtime - BetterCrashesCompat 的归属
• 帧节流内核 - 同属 rendering/ 顶层的另一子系统