Java 异常分类模型

保障应用系统的稳定性离不开对运行时错误的精细管控。Java 语言通过完善的异常栈架构，使开发者能够拦截和处理执行过程中的错误。掌握异常类型的划分及相应的响应策略，是构建高可用服务的基石。

受检与非受检异常的区别

JVM 将异常对象划分为两大阵营：必须被捕获或向上抛出的受检异常（Checked Exception），以及编译器不强制干预的运行时异常（RuntimeException）。辨析这两者的行为模式，对于设计合理的 API 接口至关重要。

受检异常主要源自外部环境的变动或非法操作，例如读取文件时路径不存在。这类异常通常由标准库抛出，开发者若不调用 try-catch 结构捕获，必须在方法签名中使用 throws 显式告知调用方。

public void fetchConfiguration(String path) throws FileNotFoundException {
    try {
        Files.readAllLines(Paths.get(path));
    } catch (IOException e) {
        throw new InvalidPathException("配置加载失败", null);
    }
}

相比之下，运行时异常源于逻辑谬误，如空指针引用或算术错误。这类问题通常代表代码本身存在缺陷，应当通过优化逻辑来消除，而非依赖捕获机制兜底。

控制流语句的执行规范

try-catch-finally 结构是 Java 处理异常的标准范式。理解各个区块的执行优先级，能有效防止资源泄露或意外状态覆盖。

Catch 块的匹配顺序

当多个异常同时出现的可能性存在时，必须按照继承树结构排序 Catch 块。具体子类必须在通用父类之前捕获，否则会导致编译错误。Java 运行时引擎会自上而下依次尝试匹配。

public void processRequest(Request req) {
    try {
        validate(req);
    } catch (NullPointerException npe) {
        log.error("输入参数为空", npe);
    } catch (Exception ex) {
        log.warn("未知错误", ex);
    }
}

Finally 块的优先级

无论是否发生异常，finally 块中的代码都会被执行，常用于关闭流或释放连接。特别需要注意的是，如果 finally 块内部再次抛出异常，它将打断并掩盖原本 try 或 catch 中产生的异常信息。

public void releaseConnection(Connection conn) {
    try {
        conn.close();
    } catch (SQLException sqle) {
        logger.error(sqle.getMessage());
    } finally {
        // 若在清理阶段也发生错误，原始异常将被丢失
        conn = null; 
    }
}

静默失效的潜在危害

捕获异常却没有任何记录或处置，被称为"吞异常"行为。这种开发习惯极具隐蔽性，它会切断调试链路，导致后续业务逻辑基于不可知的状态继续运行。

public void loadData() {
    try {
        repository.fetch();
    } catch (DataAccessException e) {
        // 直接忽略，系统看似正常但数据缺失
    }
    
    renderView(loadResult); // 此时结果可能为 Null
}

在上述场景中，由于异常被静默消化，后续调用渲染视图的方法时，变量 loadResult 并未初始化，极易引发空指针错误。即便无法立即恢复业务，至少应当在日志系统中记录堆栈信息。

try {
    initializeService();
} catch (InitializationError err) {
    logger.fatal("服务初始化崩溃，请检查依赖项", err);
    Thread.currentThread().interrupt();
}

重写方法的异常契约

在进行多态方法重写时，子类抛出的异常范围不能大于父类。若父类声明了特定的受检异常，子类要么保留该异常声明，要么选择转为更具体的子类异常抛出，严禁扩大异常边界。