Java如何建立全工程受检异常与非受检异常的Review全景检查清单-java教程-PHP中文网

java中受检异常是继承exception但非runtimeexception的异常，编译器强制处理；非受检异常包括runtimeexception及其子类、error及其子类，编译器不强制处理。

java如何建立全工程受检异常与非受检异常的review全景检查清单

明确受检异常与非受检异常的边界

Java中，受检异常（Checked Exception）是继承自Exception但不继承自RuntimeException的异常，编译器强制要求处理（try-catch或throws）；非受检异常（Unchecked Exception）是RuntimeException及其子类、以及Error及其子类，编译器不强制处理。建立检查清单前，必须统一团队对这两类异常的识别标准，避免将IllegalArgumentException误判为受检异常，或将自定义的BusinessException extends Exception遗漏为未声明受检异常。

扫描全工程异常使用模式的4个关键维度

针对每个模块/包/服务，逐项核查以下四类场景：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

方法签名层面：检查所有public/protected方法是否在throws子句中完整声明了抛出的受检异常；特别注意Spring @Service方法被AOP代理后，异常传播是否被意外吞没
调用链层面：追踪跨模块调用（如FeignClient、Dubbo接口、本地Service调用），确认上游是否感知并适配了下游抛出的受检异常；例如调用一个声明throws IOException的工具类方法，却未捕获或声明，属于典型漏检
异常包装与转换层面：审查是否在日志记录、统一异常处理器（@ControllerAdvice）、或DTO转换过程中，把受检异常静默转为RuntimeException（如new RuntimeException(e)），导致原始受检语义丢失且无法被调用方预期处理
资源管理层面：重点检查IO、JDBC、NIO等涉及资源释放的代码，是否用try-with-resources或finally确保关闭；若因忽略IOException等受检异常导致资源泄漏，需在清单中标记为高危项

构建可落地的自动化+人工协同检查机制

纯人工Review效率低且易遗漏，建议分层实施：

用SpotBugs（含findsecbugs插件）配置规则REC_CATCH_EXCEPTION、DE_MIGHT_IGNORE、EXC_NULL_POINTER_TO_NONNULL等，自动标记空catch、忽略异常、未处理受检异常等风险点
编写自定义Checkstyle规则或使用archunit断言，例如禁止在controller层直接throws受检异常（应由统一异常处理器拦截），或禁止service方法throws SQLException（应封装为业务异常）
在CI流水线中嵌入检查：Maven构建时启用-Dmaven.compiler.source=17 -Dmaven.compiler.target=17并配合maven-pmd-plugin扫描异常处理缺陷，失败则阻断发布
人工复查聚焦“为什么”：对每处throws或catch标注业务含义——这个异常是否真的可能由当前上下文触发？调用方是否有合理方式恢复？是否应降级而非中断？

维护一份动态更新的团队异常规范文档

检查清单不是一次性的交付物，而是演进中的治理资产。建议包含：

受检异常白名单：仅允许在特定场景使用的受检异常（如InterruptedException在线程协作中、IOException在文件操作中），其余一律转为定制的非受检业务异常
异常转换映射表：例如SQLException → DataAccessException（Spring风格）、HttpClientErrorException → ApiCallException，明确包装时机与构造参数（是否保留cause、是否添加traceId）
各层异常处理契约：DAO层可抛受检异常；Service层只抛业务异常（非受检）；Controller层不抛异常，由全局处理器转HTTP状态码；异步任务（@Async）中未捕获异常默认丢失，必须显式记录或重抛
历史问题归档：记录曾因异常处理不当引发的线上故障（如某次TimeoutException未被捕获导致线程池耗尽），作为新成员培训案例