Java受检异常是编译期强制处理的Exception子类（非RuntimeException），旨在提升健壮性，但因破坏封装、增加维护成本备受争议；实践中应分场景使用，强依赖外部资源时保留，业务逻辑异常则推荐运行时异常配合全局处理。
Java的受检异常（Checked Exception）机制，是编译期强制要求处理的异常类型，其设计初衷是提升程序健壮性——让开发者在编码阶段就直面可能发生的、可恢复的外部问题。但多年实践下来，它已成为Java生态中争议最持久的设计之一。
受检异常的核心特征
它必须继承自Exception，且不能是RuntimeException或其子类；典型代表包括IOException、SQLException、ClassNotFoundException等。编译器会检查每个可能抛出这类异常的方法调用：要么用try-catch捕获，要么在方法签名中用throws声明——否则直接报错，无法通过编译。
支持它的理由：显式契约与早期防御
受检异常把“可能出现的问题”提前暴露在方法签名里，形成一种隐含的接口契约。比如FileReader构造器声明throws FileNotFoundException，调用者一眼就知道：文件路径是否有效、是否存在，是这个操作的前提条件。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 强制关注资源类操作（如IO、数据库），减少因忽略关闭流或连接导致的泄漏
- 在强依赖外部系统（如支付回调、文件写入）的场景中，提醒开发者设计重试、降级或人工介入策略
- 相比返回码或布尔标志，异常携带更丰富的上下文（堆栈、cause链），利于定位和监控
反对它的现实痛点：破坏封装与维护成本高
当底层方法新增一个受检异常，整个调用链上的所有中间方法都得被迫修改签名——加throws或加try-catch，哪怕它们只是透传。这种“牵一发而动全身”的连锁反应，违背了开闭原则，也让模块演进变得脆弱。
立即学习“Java免费学习笔记（深入）”；
- Spring、Dubbo等主流框架默认不传播受检异常语义，序列化后只剩message和cause，类型信息丢失
- REST API或跨语言调用时，前端只认HTTP状态码+业务code，Java的checked/unckecked区分毫无意义
- 大量空catch、生硬包装成RuntimeException，反而掩盖真正需处理的问题
现代Java项目的务实取舍
不是全盘否定，而是分场景判断。真正需要受检异常的场景其实很窄：外部资源强依赖、失败后必须显式恢复（如定时任务写日志失败需告警+人工核查）。其余绝大多数业务异常——比如参数校验失败、余额不足、库存超卖——本质是流程分支，不是“系统出错了”，更适合用带业务语义的运行时异常（如BusinessException）配合全局统一响应体处理。
- 用@ControllerAdvice集中捕获并转为标准JSON格式（code/msg/data）
- 异常对象内嵌关键业务字段（orderId、userId），方便日志提取与链路追踪
- 必要时借助Lombok的@SneakyThrows简化样板代码，但不滥用
