异常体系结构与核心设计思想

Java的异常体系以 Throwable 为根类，其下分为 Error 和 Exception 两大分支。其中 Error 表示系统级严重错误，如内存溢出或栈溢出，通常不可恢复，程序不应尝试捕获。而 Exception 是可处理的运行时问题，进一步细分为受检异常（Checked）与非受检异常（Unchecked），后者继承自 RuntimeException。

受检异常与非受检异常的区别

• 受检异常：编译期强制要求处理，例如 IOException、SQLException，适用于外部资源操作失败等场景。
• 非受检异常：运行时抛出，无需显式声明，如 NullPointerException、IllegalArgumentException，应通过代码逻辑预防而非依赖捕获。

异常处理流程与底层实现

异常处理依赖五个关键字： try、catch、finally、throw、throws。其中 try-catch-finally 构成标准结构，finally 块用于资源释放，但若内部使用 return 将覆盖原有返回值，需谨慎。

JVM通过 异常表（Exception Table） 实现异常定位。每个方法生成的字节码中包含若干条目，记录了：

• from：监控起始位置
• to：监控结束位置
• target：异常处理器入口
• type：目标异常类型

当异常发生时，JVM会查找异常表，匹配范围与类型后跳转至对应 catch 块执行。

异常链与信息保留

在封装异常时，应保留原始异常上下文，便于排查根源。推荐使用带 cause 参数的构造函数：

try {
    // 模拟文件读取
} catch (IOException ex) {
    throw new BusinessLogicException("数据加载失败", ex);
}

常见异常及规避策略

异常类型	触发原因	应对方式
NullPointerException	调用空引用的方法或字段	使用 Objects.requireNonNull() 校验参数；避免深层链式调用
ConcurrentModificationException	迭代期间修改集合结构	使用迭代器的 remove()；或选用并发容器如 CopyOnWriteArrayList
ClassCastException	类型转换不兼容	先判断 instanceof 再强转；优先使用泛型
IllegalArgumentException	传入非法参数	在方法开始处进行参数校验

自定义异常的设计规范

当内置异常无法表达业务语义时，应创建自定义异常。设计原则包括：

• 根据是否需强制处理决定父类：继承 Exception 为受检异常，继承 RuntimeException 为非受检异常。
• 增强异常上下文信息，如添加错误码、订单编号等业务字段。
• 避免过度细分，可通过一个通用异常配合不同错误码区分场景。

public class ServiceFailureException extends RuntimeException {
    private final String errorCode;
    private final Map metadata;

    public ServiceFailureException(String code, String msg, Map meta) {
        super(msg);
        this.errorCode = code;
        this.metadata = meta;
    }

    // getter methods
}

最佳实践与典型反模式

遵循以下建议提升代码健壮性：

• 精准捕获：避免使用 catch (Exception e)，应指定具体异常类型。
• 自动资源管理：优先使用 try-with-resources 语法，确保资源及时释放。
• 异常转换：在应用层将技术异常转化为业务异常，隐藏底层细节。

反模式	风险	正确做法
异常吞噬	捕获后无日志或未重新抛出，导致问题难追踪	至少记录日志，或向上抛出异常
忽略异常链	新建异常时丢失原始堆栈信息	使用带 cause 构造函数
finally 中 return	覆盖 try/catch 的返回结果	finally 只用于清理资源，禁止返回
滥用异常控制流程	在循环中抛异常来跳出，性能极差	使用条件判断代替异常跳转

性能注意事项

异常实例创建成本较高，因需生成完整的栈跟踪信息。因此，绝不应在高频执行路径中使用异常作为控制流手段。对于可预见的情况，应采用 if-else 判断替代异常处理。