受检异常与运行时异常怎么用？

在企业级Java开发中，异常选型本质是系统契约设计：运行时异常应成为表达业务规则和内部错误的主流选择，而受检异常仅限于第三方SDK、金融强保障等少数需强制调用方响应的场景；通过基础设施层封装原始异常、应用层抛语义化业务异常、网关层统一标准化响应的分层策略，既能提升代码可读性与可维护性，又能清晰界定“可恢复”与“不可恢复”的边界，配合工程化检查、统一异常基类和精准文档，真正让异常成为业务逻辑的有机组成部分，而非混乱的错误处理负担。

在企业级开发中，受检异常（Checked Exception）与运行时异常（RuntimeException）的选型不是语法问题，而是设计契约问题：它决定了调用方是否必须显式处理、异常是否属于业务流程的一部分、以及系统能否清晰表达“可恢复”与“不可恢复”的边界。

明确异常分类的核心原则

Java 异常体系的设计初衷是让开发者区分两类问题：

• 受检异常：表示调用方合理预期可能遇到且有能力恢复的外部不确定性，比如文件不存在、网络超时、数据库连接失败。这类异常强制编译器介入，迫使调用链上某一层做决策（重试、降级、提示用户、记录并转为业务错误等）。
• 运行时异常：表示程序逻辑错误或不可恢复的内部状态异常，比如空指针、数组越界、参数非法（违反前置条件）、数据不一致。它们不强制捕获，应通过代码审查、单元测试和防御性编程提前规避，而非靠 try-catch 挽救。

企业项目中推荐的异常建模方式

避免直接抛出 IOException 或 SQLException 这类通用受检异常。应在领域层定义语义清晰的自定义异常，并按职责分层封装：

• 基础设施层（DAO/Client）：捕获原始受检异常（如 SQLException），转换为统一的、带上下文的运行时异常（如 DataAccessException），不向上抛受检异常。这是 Spring 等主流框架的实践基础。
• 应用服务层（Service）：对业务规则校验失败（如“余额不足”、“订单已关闭”）抛出自定义的 运行时异常（如 InsufficientBalanceException）。这类异常本质是业务流的分支，不是意外，应由上层（如 Controller）统一捕获并转化为 HTTP 状态码或错误码。
• 网关/接口层（Controller/Api）：只处理最终面向调用方的异常。将所有异常（包括运行时异常）统一拦截，映射为标准响应体（如 { "code": "BUSINESS_ERROR", "message": "库存不足" }），并控制是否记录堆栈（敏感信息不外泄）。

哪些场景仍需谨慎使用受检异常

并非完全弃用受检异常。在以下有限场景中，保留受检异常能强化契约、提升可维护性：

• 开放给第三方使用的 SDK 或公共 API 包，需要强制调用方意识到某些失败必须处理（如证书过期、配额超限）；
• 核心金融交易流程中，某些外部依赖（如支付网关回调确认）失败后，业务上必须人工介入或走补偿流程，此时用受检异常可防止开发者“静默忽略”；
• 遗留系统集成桥接层，需严格遵循老协议的错误语义，且调用方无法升级框架时，可封装为受检异常并附带清晰 Javadoc 说明恢复策略。

团队落地的关键配套措施

规范选型不能只靠约定，需工程化保障：

• 在代码检查工具（如 SonarQube、Checkstyle）中配置规则：禁止在 service 层 throws 原始 JDBC/IO 受检异常；禁止在 controller 层 catch RuntimeException 后吞掉或裸 throw；
• 建立团队共享的异常基类体系，例如：BizException（运行时，用于业务规则）、SystemException（运行时，用于系统故障）、ExternalException（受检，仅限 SDK 或特定集成场景）；
• 每个自定义异常必须有明确的文档说明：触发条件、是否可重试、建议恢复动作、是否需告警、是否计入监控指标。

今天关于《受检异常与运行时异常怎么用？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！