Java 异常机制全解析：从原理到工程实践

面向后端工程的系统化认知与可落地的最佳实践

概述

异常是程序在运行过程中出现的“非期望状态”的结构化表达，它承载错误语义、传播路径与恢复策略。合理的异常机制能将“错误”从“业务主路径”中剥离，使代码更清晰、可诊断、可维护。

简介与项目背景

在典型的 Spring/Spring Boot 电商后端中，服务层与网关层需要对接复杂外部系统与基础设施（数据库、缓存、RPC、文件 IO）。这些交互的失败必须被可靠捕获并转化为面向调用方的稳定契约（错误码/消息/HTTP 状态），避免把底层细节泄露到上层业务。

名词解释

• 异常（Exception）：运行时出现问题的对象化表达，包含类型、消息、堆栈与根因（Cause）。
• 受检异常（Checked Exception）：编译器强制处理（声明或捕获）的异常类型。
• 非受检异常（Unchecked Exception）：运行时异常（RuntimeException 及其子类）与 Error，编译器不强制处理。
• 异常链（Cause）：异常之间的因果引用，保留根因以便定位问题。
• 抑制异常（Suppressed Exception）：在 try-with-resources 自动关闭资源时，关闭过程的异常被“附加”为 suppressed，避免覆盖主异常。

1. 异常是什么？为什么需要异常机制

• 将错误从正常流程中“抽离”为结构化信号，减少嵌套判断。
• 支持跨层传播与统一处理，保持业务主路径简洁。
• 可携带上下文（错误码、参数、环境信息），提升可诊断性。

2. Java 异常体系总览（Throwable 树）

下图以 Mermaid 展示 Throwable 体系，并通过颜色/样式缓解视觉疲劳：

3. Checked vs Unchecked：本质区别与工程取舍

• 受检异常（Checked）：编译期强制处理；适合“可恢复”的外部交互失败（IO/RPC/SQL），迫使调用方明确策略。
• 非受检异常（Unchecked）：编译器不强制；适合“编程错误/不变量破坏”（NPE/IAE/ISE），交由统一异常处理收敛。

3.1 Checked（受检异常）

• 语义：外部环境可恢复失败（网络波动、磁盘满、权限不够）。
• 处理策略：就地重试/降级/回退，或向上抛出给统一异常处理。
• 设计建议：对重要外部交互边界，倾向保留 IOException / SQLException 等受检异常并在适当层转换为业务异常。

3.2 Unchecked（非受检异常）

• 语义：代码不变量违反、契约误用、编程错误。
• 处理策略：不要在每处 try-catch，交由全局异常处理；在单元测试阶段及时暴露并修正。
• 典型示例：NullPointerException、IllegalArgumentException、IllegalStateException。

3.3 实战建议（重要）

• 输入校验失败抛 IllegalArgumentException，状态不合法抛 IllegalStateException。
• 外部交互失败优先保留受检异常，在边界层统一转换为业务异常。
• 绝不在底层“吞异常”，必须保留 cause 和上下文。

4. try-catch-finally 语义细节（面试高频）

• try 块：包裹可能抛出异常的代码。
• catch 块：按“从子类到父类”的顺序匹配处理。
• finally 块：用于释放资源，几乎总会执行，但存在少数不执行场景。

4.1 finally 一定会执行吗？

• 正常情况是会：无论是否抛异常。
• 不执行情况：System.exit(0)、JVM 崩溃、进程被杀、死循环/死锁阻塞等。

4.2 catch 顺序：从子类到父类

• 先捕获具体子类，再是父类；否则子类永远匹配不到。

4.3 finally 里不要 return / throw（非常重要）

• 在 finally 中 return/throw 会“覆盖”try/catch 的返回或异常，导致主异常丢失，极难排查。

示例代码（错误与正确对比）：

try {
    risky();
} catch (SpecificException e) { // 子类先于父类
    log.error("specific", e);
    throw e; // 保留主异常
} catch (Exception e) {
    log.error("generic", e);
    throw e;
} finally {
    closeQuietly(resource); // 切勿在此 return/throw
}

5. try-with-resources：资源关闭的最佳方式

• 自动关闭实现 AutoCloseable 的资源，语义更安全，代码更简洁。
• 能自动产生 suppressed 异常，避免覆盖主异常。

示例代码：

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
} // br.close() 将在此自动执行

5.1 suppressed 异常是什么？

• 如果读取过程中抛出主异常 A，而关闭资源又抛出异常 B，则 B 不会覆盖 A，而是作为 suppressed 挂在 A 上：A.addSuppressed(B)。
• 记录 suppressed 便于完整诊断资源泄漏。

6. 异常链（Cause）与“保留根因”原则

• 使用构造函数或 initCause() 设置 cause，确保异常链可追溯。
• 在转换异常时，务必携带原始 cause：new BizException(code, msg, e)。

7. 自定义业务异常：高质量设计模板

7.1 为什么要自定义业务异常？

• 将技术异常与业务异常分层，向上游暴露稳定的错误码与可读消息；便于统一拦截与统计。

7.2 推荐结构：错误码 + 可读消息 + 可选上下文

public class BizException extends RuntimeException {
    private final String code;
    private final String readableMessage;
    private final Map<String, Object> context; // 可选上下文

    public BizException(String code, String readableMessage) {
        super(readableMessage);
        this.code = code;
        this.readableMessage = readableMessage;
        this.context = Collections.emptyMap();
    }

    public BizException(String code, String readableMessage, Throwable cause, Map<String, Object> context) {
        super(readableMessage, cause); // 保留根因
        this.code = code;
        this.readableMessage = readableMessage;
        this.context = context == null ? Collections.emptyMap() : context;
    }

    public String getCode() { return code; }
    public String getReadableMessage() { return readableMessage; }
    public Map<String, Object> getContext() { return context; }
}

8. Spring/Spring Boot 项目中的统一异常处理（常用范式）

• 使用 @ControllerAdvice + @ExceptionHandler 统一拦截，将异常映射为统一响应（错误码/消息/HTTP 状态）。

示例代码：

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(BizException.class)
    public ResponseEntity<ErrorResponse> handleBiz(BizException e) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(
            ErrorResponse.of(e.getCode(), e.getReadableMessage(), e.getContext())
        );
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGeneric(Exception e) {
        // 记录完整堆栈 + 关联请求上下文
        log.error("unhandled exception", e);
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(
            ErrorResponse.of("INTERNAL_ERROR", "系统繁忙，请稍后再试", Map.of("traceId", MDC.get("traceId")))
        );
    }
}

9. 异常处理的经典反模式（高频踩坑）

• 9.1 捕获后什么都不做：吞异常，导致隐性失败与数据不一致。
• 9.2 用异常做正常流程控制：影响性能与可读性，应改为返回值或枚举。
• 9.3 只打印 e.getMessage() 不打印堆栈：丢失关键信息。
• 9.4 捕获后丢失 cause：转换异常不传递原始 cause。
• 9.5 在 finally 里做关键业务逻辑：若未执行将造成严重后果。

10. 常见运行时异常速查（附触发原因与建议）

• NullPointerException：未初始化/链式调用空对象 → 空值检查、Optional、单元测试覆盖。
• IllegalArgumentException：入参非法 → 参数校验框架（Hibernate Validator）、边界测试。
• IllegalStateException：状态不合法 → 生命周期管理、状态机建模。
• ClassCastException：错误的类型转换 → 泛型约束、避免不安全强转。

11. 如何写出“可诊断”的异常信息（日志与消息技巧）

• 错误码具名、消息可读且包含关键参数（但避免敏感信息）。
• 日志记录“完整堆栈 + 上下文”（traceId、用户、请求 URI、配置切面）。
• 对外错误消息与对内日志分离：避免泄露内部细节。
• 统一格式：[code] message | ctx={k1=v1,k2=v2}，便于检索。

12. 一套推荐的异常分层策略（适合大多数后端项目）

• 接口适配层：将外部受检异常转换为领域内业务异常，保留 cause 与上下文。
• 领域服务层：只抛业务异常（Runtime），不直接暴露技术细节。
• 基础设施层：使用受检异常标识交互失败，或封装为语义化异常。
• 应用/接口层统一拦截：@ControllerAdvice 汇总为标准响应。

参考资料（权威/可延展）

• Oracle Java 官方文档：Exceptions（https://docs.oracle.com/javase/tutorial/essential/exceptions/）
• Java 语言规范 JLS 第 11 章：Exceptions（https://docs.oracle.com/javase/specs/jls/se17/html/jls-11.html）
• Effective Java（3rd Edition）Item 69-77：异常的最佳实践
• Spring 文档：Web 异常处理与 @ControllerAdvice

速记口（面试/实战复盘）

• “原则三连”：保留根因、统一拦截、分层转换。
• “四不要”：不要吞异常、不要 finally return、不要只打 message、不要丢 cause。
• “场景归纳”：外部失败用受检、编程错误用非受检、API 边界转业务异常。

附：可复用代码片段索引

• try-catch-finally 示例
• try-with-resources 示例
• BizException 模板
• Spring 统一异常处理

27. 底层源码解析：Throwable/Exception 的核心实现

理解 JDK 源码中的异常实现，有助于写出更可诊断、性能更优的异常处理。

核心字段（OpenJDK 设计要点，简化说明）：

• detailMessage：异常的可读消息
• cause：异常根因（缺省为 null），通过构造函数或 Throwable.initCause() 设置
• stackTrace：StackTraceElement[]，通过 Throwable.fillInStackTrace() 构建
• suppressedExceptions：延迟初始化的列表，用于记录 addSuppressed() 添加的抑制异常（try-with-resources 关闭阶段产生）

关键方法（语义摘要）：

• Throwable.fillInStackTrace()：Native 层采集当前线程的调用栈，填充为 StackTraceElement[]
• Throwable.getStackTrace()：返回不可变拷贝的堆栈数组
• Throwable.addSuppressed(Throwable)：将关闭阶段的异常追加到主异常的 suppressed 列表（自我抑制和 null 参数会被拒绝）
• 构造器重载：Throwable(Throwable cause, boolean enableSuppression, boolean writableStackTrace) 等，用于控制是否启用 suppressed 和是否写入堆栈

示例（高频构造器用法：禁用堆栈以降低开销——谨慎使用）：

// 高频触发但非诊断关键的异常，可考虑关闭堆栈（writableStackTrace=false）
public class LightweightBizException extends RuntimeException {
    public LightweightBizException(String code, String msg) {
        super(msg, null, true, false); // enableSuppression=true, writableStackTrace=false
        // 仍可通过统一处理输出 code，但失去详细堆栈，需审慎评估
    }
}

28. 编译器层面的 Checked 异常机制（静态约束）

• 方法签名中的 throws 列表声明可能抛出的“受检异常”，编译器在调用点强制要求“捕获或继续声明”，否则编译失败。
• 非受检异常（RuntimeException 及子类、Error）不受此约束。

示例：

public void readFile(String path) throws IOException { /* ... */ }

public void caller() {
    try {
        readFile("a.txt");
    } catch (IOException e) {
        // 编译器强制捕获或将 IOException 继续声明在 caller 的 throws 列表中
        log.error("io failed", e);
        throw new BizException("IO-READ-001", "读取文件失败", e, Map.of("path", path));
    }
}

• 编译器在语义分析阶段对受检异常进行“可达性”判断：若调用链可能抛出受检异常，则必须处理（catch）或在方法签名继续 throws，形成从下游到上游的静态约束链。

29. try-catch-finally 与 try-with-resources 的字节码形态（工作原理）

• finally 的编译策略：编译器为 finally 生成“保护块”，确保正常返回与异常路径均会执行 finally 体；异常路径中会在执行 finally 后 athrow 重新抛出。
• try-with-resources 的编译展开：编译器在关闭资源（close()）时若发生异常，会调用 addSuppressed() 将关闭异常挂载到主异常上，避免覆盖主异常。

示意伪代码（简化）：

// try-with-resources 展开要点（简化）
Resource r = acquire();
Throwable mainEx = null;
try {
    use(r);
} catch (Throwable t) {
    mainEx = t;          // 记录主异常
    throw t;
} finally {
    if (r != null) {
        if (mainEx != null) {
            try { r.close(); }
            catch (Throwable closeEx) { mainEx.addSuppressed(closeEx); } // 不覆盖主异常
        } else {
            r.close(); // 正常路径关闭
        }
    }
}

• 该展开确保“主异常优先”，关闭阶段异常作为 suppressed 附加，日志应打印主异常并枚举 suppressed 以完整诊断。

30. 性能与诊断：堆栈构建成本与优化建议

• 捕获堆栈是昂贵操作（fillInStackTrace），在高频异常场景会显著影响性能。
• 避免“用异常做正常流程控制”；对可预期的分支使用返回值或校验框架（如 Hibernate Validator）。
• 若确有高频异常且对诊断要求不高，可使用“轻量异常”（RuntimeException 构造器参数 writableStackTrace=false），但需通过 APM/日志策略保证可观测性。

诊断建议：

• 日志统一打印“主异常 + suppressed + cause 链”；见章节 15 的打印策略。
• 错误码作为检索维度（日志/告警/链路追踪系统一致）。
• 在入口设置 MDC 的 traceId，保障跨线程与异步场景的可追踪性。

31. 设计扩展思路：可观测性、策略化恢复与分类治理

• 可观测性：
  • 统一结构化日志（JSON），字段包含
  • 集成 APM（如 SkyWalking/Zipkin）、错误聚合平台（Sentry 等），自动对异常进行聚类与告警。
• 策略化恢复：
  • 对外部交互失败引入策略引擎（重试次数、退避、熔断、隔离），与异常分类绑定（如 DB-READ-*、RPC-TIMEOUT-*）。
• 分类治理：
  • 建立错误码命名空间与 Owner 归属，推动“异常分类-责任人-修复策略”的闭环。
  • 周期性异常审计：统计 Top N 异常栈，优化热点与补齐监控。

异常传播序列图（Mermaid，颜色优化）：

32. 与项目工程的改造落地建议（结合现有代码）

• 全局异常处理增强：
  • 对 BizException 输出标准结构（ProblemDetail/自定义 ErrorResponse），附带 code/traceId/context。
  • 对常见非受检异常（IAE/ISE/NPE）区分 400/500 响应，避免泄漏技术细节。
• 边界层策略：
  • Adapter/Infra 层保留受检异常，进入领域层统一封装为业务异常，使用 BizException 保留根因。
• 观测与日志：
  • 在入口拦截器/切面统一生成并清理 MDC 的 traceId。
  • 日志模板包含 code 与 context，便于检索与归因。
• 异常分类与错误码：
  • 建立“系统-模块-编号”命名空间（如 CART-ITEM-001），在统一处理层作为响应字段返回，并作为监控维度。

33. 设计复盘与架构分层图（增强版）

34. 实操清单（更新版）

• 在边界层将外部受检异常转换为领域 BizException，保留 cause 与上下文。
• 统一异常处理输出标准化错误响应（ProblemDetail/ErrorResponse），携带 code/traceId/context。
• 日志打印完整堆栈 + suppressed；入口放置并清理 MDC。
• 禁止 finally 中 return/throw；资源关闭使用 try-with-resources。
• 按决策树区分 Checked/Unchecked；错误码命名空间与监控对齐。
• 对外消息 i18n；对内日志含诊断细节且不泄露敏感信息。
• 审计 Top N 异常栈与热点，迭代修复与治理。

– 完 –

13. REST API 错误响应设计（RFC 7807 / ProblemDetail）

现代 REST 接口推荐使用标准化错误响应，提升跨端一致性与可诊断性。Spring 6+ 内置 ProblemDetail 支持，可用统一异常处理映射为结构化响应。

示例：推荐响应结构（兼容 RFC 7807）

{
  "type": "https://example.com/errors/CART-ITEM-001",
  "title": "参数非法",
  "status": 400,
  "detail": "skuId 缺失或格式不正确",
  "instance": "add",
  "code": "CART-ITEM-001",
  "traceId": "a1b2c3d4",
  "context": { "skuId": null, "userId": 12345 }
}

Spring 6+ 映射示例（将业务异常转换为 ProblemDetail）：

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(BizException.class)
    public ResponseEntity<ProblemDetail> handleBiz(BizException e) {
        ProblemDetail pd = ProblemDetail.forStatus(HttpStatus.BAD_REQUEST);
        pd.setTitle("业务异常");
        pd.setDetail(e.getReadableMessage());
        pd.setType(URI.create("https://example.com/errors/" + e.getCode()));
        pd.setProperty("code", e.getCode());
        pd.setProperty("traceId", MDC.get("traceId"));
        pd.setProperty("context", e.getContext());
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(pd);
    }
}

14. 日志与追踪：MDC / TraceId / 上下文关键信息

• 统一在入口（过滤器/切面）生成 TraceId，写入 MDC，贯穿全链路。
• 异常日志规范：记录完整堆栈 + 关键上下文（用户、URI、入参摘要、下游依赖标识）。
• 避免敏感信息（密码、隐私数据）出现在日志与对外消息中。

MDC 放置与清理示例：

try {
    MDC.put("traceId", traceIdGenerator.next());
    // 业务处理
} finally {
    MDC.clear(); // 确保清理，避免线程复用导致污染
}

Logback pattern 示例（包含 traceId）：

logging.pattern.level=%5p [traceId=%X{traceId}]

15. suppressed 异常与资源关闭排查（实战打印）

• 主异常与资源关闭异常同时出现时，关闭异常会作为 suppressed 挂在主异常上，应当在日志中打印出来，避免漏诊。

示例打印方法：

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
} catch (IOException e) {
    log.error("IO failed", e);
    for (Throwable sup : e.getSuppressed()) {
        log.error("suppressed during close: {}", sup.toString(), sup);
    }
    throw e;
}

16. 异常链构建与打印策略（保留根因原则的落地）

• 异常转换时携带原始 cause：new BizException(code, msg, cause)。
• 打印时优先打印顶层异常（含 cause 链与 suppressed），便于一次定位。

异常链示例：

try {
    callDownstream();
} catch (SQLException ex) {
    throw new BizException("DB-READ-001", "读取订单失败", ex, Map.of("orderId", orderId));
}

17. 错误码设计：命名空间 + 语义清晰 + 可检索

推荐规则：

• 分层命名：系统-模块-编号，如：CART-ITEM-001、CART-CHECKOUT-002。
• 编号区间：预留扩展空间（000-099 通用、100-199 参数、200-299 资源、300-399 下游、400-499 权限）。
• 与监控/告警对齐：错误码作为检索维度（Log/APM/Metric 统一）。
• 语义明确：一眼知道问题类别与定位范围。

示例表（建议）：

CART-ITEM-001 参数非法
CART-ITEM-201 资源不存在
CART-CHECKOUT-301 下游依赖超时
CART-SECURITY-401 未授权访问

18. i18n 多语言消息与对外/对内信息分离

• 对外消息（用户可见）采用 i18n（MessageSource），避免暴露内部技术细节。
• 对内日志（工程师可见）包含技术细节（异常链、堆栈、上下文）。
• 响应中携带 code + 可读消息，前端再根据 locale 显示本地化提示。

i18n 示例：

String msg = messageSource.getMessage("cart.param.invalid", new Object[]{ "skuId" }, locale);
// 作为 BizException 的 readableMessage
throw new BizException("CART-ITEM-001", msg, cause, Map.of("skuId", skuId));

19. Spring Boot 项目统一异常处理落地范式（结合现有工程）

• 统一异常处理类：
• 建议增强：
  • 对 BizException 映射为统一结构（ProblemDetail / 自定义 ErrorResponse），携带 code、traceId、context。
  • 对常见非受检异常（IAE/ISE/NPE）统一转换为 400/500 级响应，避免泄漏底层信息。
  • 在入口切面或拦截器中放置 TraceId（MDC），异常日志统一打印。
  • 针对下游依赖（RPC/DB/Cache）故障，保留 cause 并转业务异常，减少调用方理解成本。

20. 反模式代码对照（含修正示例）

• 吞异常（wrong）：

try { risky(); } catch (Exception e) { /* ignore */ }

• 修正（right）：

try { risky(); } catch (SpecificException e) {
    log.error("risky failed", e);
    throw new BizException("CART-OPS-301", "依赖调用失败", e, Map.of("op", "risky"));
}

• 只打印 message（wrong）：

catch (Exception e) { log.error("failed: {}", e.getMessage()); }

• 修正（right）：

catch (Exception e) { log.error("failed", e); }

• 在 finally 中 return（wrong）：

try { return compute(); } finally { return -1; }

• 修正（right）：

try { return compute(); } finally { cleanup(); }

21. Checked vs Unchecked 决策树（Mermaid 颜色优化）

22. 异常分层架构图（分层职责与颜色优化）

23. 最佳实践清单（Checklist）

• 在边界层转换外部失败为业务异常，保留 cause 与上下文。
• 统一异常处理输出标准化错误响应（ProblemDetail/自定义结构）。
• 日志记录完整堆栈 + 关键上下文；入口放置 TraceId。
• 禁止在 finally 中 return/throw；资源关闭使用 try-with-resources。
• 区分 Checked/Unchecked：外部可恢复失败 vs 编程错误。
• 错误码命名空间语义清晰，作为检索维度贯穿监控。
• 对外消息 i18n；对内日志包含诊断细节但不泄露敏感信息。
• 单元测试覆盖异常分支与消息/错误码一致性。

24. 速记口诀（增强版）

• “三原则”：保留根因｜统一拦截｜分层转换
• “四禁令”：禁吞异常｜禁 finally return｜禁只打 message｜禁丢 cause
• “两分法”：外部失败→受检；编程错误→非受检
• “一规范”：错误响应标准化（ProblemDetail/RFC7807）

25. FAQ（高频问题）

• Q：为什么不建议 everywhere try-catch？
  • A：污染主路径，易吞异常，难统一处理；建议在统一拦截处集中收敛。
• Q：什么时候用受检异常？
  • A：外部交互可恢复、需要调用方明确策略时（IO/RPC/DB）。
• Q：如何避免 finally 覆盖主异常？
  • A：finally 只做资源释放，不进行 return/throw。

26. 参考资料（扩展）

• RFC 7807: Problem Details for HTTP APIs（https://datatracker.ietf.org/doc/html/rfc7807）
• Spring Framework 6: ProblemDetail（https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-ann-rest-exceptions.html）
• Logback + MDC 官方文档（https://logback.qos.ch/manual/mdc.html）
• Effective Java（3rd）Items 69-77：异常实践
• Oracle 官方教程：Exceptions（https://docs.oracle.com/javase/tutorial/essential/exceptions/）

– 完 –

27. 底层源码解析：Throwable/Exception 的核心实现

理解 JDK 源码中的异常实现，有助于写出更可诊断、性能更优的异常处理。

核心字段（OpenJDK 设计要点，简化说明）：

• detailMessage：异常的可读消息
• cause：异常根因（缺省为 null），通过构造函数或 Throwable.initCause() 设置
• stackTrace：StackTraceElement[]，通过 Throwable.fillInStackTrace() 构建
• suppressedExceptions：延迟初始化的列表，用于记录 addSuppressed() 添加的抑制异常（try-with-resources 关闭阶段产生）

关键方法（语义摘要）：

• Throwable.fillInStackTrace()：Native 层采集当前线程的调用栈，填充为 StackTraceElement[]
• Throwable.getStackTrace()：返回不可变拷贝的堆栈数组
• Throwable.addSuppressed(Throwable)：将关闭阶段的异常追加到主异常的 suppressed 列表（自我抑制和 null 参数会被拒绝）
• 构造器重载：Throwable(Throwable cause, boolean enableSuppression, boolean writableStackTrace) 等，用于控制是否启用 suppressed 和是否写入堆栈

示例（高频构造器用法：禁用堆栈以降低开销——谨慎使用）：

// 高频触发但非诊断关键的异常，可考虑关闭堆栈（writableStackTrace=false）
public class LightweightBizException extends RuntimeException {
    public LightweightBizException(String code, String msg) {
        super(msg, null, true, false); // enableSuppression=true, writableStackTrace=false
        // 仍可通过统一处理输出 code，但失去详细堆栈，需审慎评估
    }
}

28. 编译器层面的 Checked 异常机制（静态约束）

• 方法签名中的 throws 列表声明可能抛出的“受检异常”，编译器在调用点强制要求“捕获或继续声明”，否则编译失败。
• 非受检异常（RuntimeException 及子类、Error）不受此约束。

示例：

public void readFile(String path) throws IOException { /* ... */ }

public void caller() {
    try {
        readFile("a.txt");
    } catch (IOException e) {
        // 编译器强制捕获或将 IOException 继续声明在 caller 的 throws 列表中
        log.error("io failed", e);
        throw new BizException("IO-READ-001", "读取文件失败", e, Map.of("path", path));
    }
}

• 编译器在语义分析阶段对受检异常进行“可达性”判断：若调用链可能抛出受检异常，则必须处理（catch）或在方法签名继续 throws，形成从下游到上游的静态约束链。

29. try-catch-finally 与 try-with-resources 的字节码形态（工作原理）

• finally 的编译策略：编译器为 finally 生成“保护块”，确保正常返回与异常路径均会执行 finally 体；异常路径中会在执行 finally 后 athrow 重新抛出。
• try-with-resources 的编译展开：编译器在关闭资源（close()）时若发生异常，会调用 addSuppressed() 将关闭异常挂载到主异常上，避免覆盖主异常。

示意伪代码（简化）：

// try-with-resources 展开要点（简化）
Resource r = acquire();
Throwable mainEx = null;
try {
    use(r);
} catch (Throwable t) {
    mainEx = t;          // 记录主异常
    throw t;
} finally {
    if (r != null) {
        if (mainEx != null) {
            try { r.close(); }
            catch (Throwable closeEx) { mainEx.addSuppressed(closeEx); } // 不覆盖主异常
        } else {
            r.close(); // 正常路径关闭
        }
    }
}

• 该展开确保“主异常优先”，关闭阶段异常作为 suppressed 附加，日志应打印主异常并枚举 suppressed 以完整诊断。

30. 性能与诊断：堆栈构建成本与优化建议

• 捕获堆栈是昂贵操作（fillInStackTrace），在高频异常场景会显著影响性能。
• 避免“用异常做正常流程控制”；对可预期的分支使用返回值或校验框架（如 Hibernate Validator）。
• 若确有高频异常且对诊断要求不高，可使用“轻量异常”（RuntimeException 构造器参数 writableStackTrace=false），但需通过 APM/日志策略保证可观测性。

诊断建议：

• 日志统一打印“主异常 + suppressed + cause 链”；见章节 15 的打印策略。
• 错误码作为检索维度（日志/告警/链路追踪系统一致）。
• 在入口设置 MDC 的 traceId，保障跨线程与异步场景的可追踪性。

31. 设计扩展思路：可观测性、策略化恢复与分类治理

• 可观测性：
  • 统一结构化日志（JSON），字段包含 code/title/detail/traceId/context。
  • 集成 APM（如 SkyWalking/Zipkin）、错误聚合平台（Sentry 等），自动对异常进行聚类与告警。
• 策略化恢复：
  • 对外部交互失败引入策略引擎（重试次数、退避、熔断、隔离），与异常分类绑定（如 DB-READ-*、RPC-TIMEOUT-*）。
• 分类治理：
  • 建立错误码命名空间与 Owner 归属，推动“异常分类-责任人-修复策略”的闭环。
  • 周期性异常审计：统计 Top N 异常栈，优化热点与补齐监控。

异常传播序列图（Mermaid，颜色优化）：

32. 与项目工程的改造落地建议（结合现有代码）

• 全局异常处理增强：
  • 对 BizException 输出标准结构（ProblemDetail/自定义 ErrorResponse），附带 code/traceId/context。
  • 对常见非受检异常（IAE/ISE/NPE）区分 400/500 响应，避免泄漏技术细节。
• 边界层策略：
  • Adapter/Infra 层保留受检异常，进入领域层统一封装为业务异常，使用 BizException 保留根因。
• 观测与日志：
  • 在入口拦截器/切面统一生成并清理 MDC 的 traceId。
  • 日志模板包含 code 与 context，便于检索与归因。
• 异常分类与错误码：
  • 建立“系统-模块-编号”命名空间（如 CART-ITEM-001），在统一处理层作为响应字段返回，并作为监控维度。

33. 设计复盘与架构分层图（增强版）

34. 实操清单（更新版）

• 在边界层将外部受检异常转换为领域 BizException，保留 cause 与上下文。
• 统一异常处理输出标准化错误响应（ProblemDetail/ErrorResponse），携带 code/traceId/context。
• 日志打印完整堆栈 + suppressed；入口放置并清理 MDC。
• 禁止 finally 中 return/throw；资源关闭使用 try-with-resources。
• 按决策树区分 Checked/Unchecked；错误码命名空间与监控对齐。
• 对外消息 i18n；对内日志含诊断细节且不泄露敏感信息。
• 审计 Top N 异常栈与热点，迭代修复与治理。