要让单元测试覆盖所有 catch 块，需主动触发每种预期异常并验证其处理逻辑：先明确各 catch 对应的异常来源与触发条件，再通过 mock、边界输入等方式精准注入异常，最后断言返回值、状态变更、日志或新异常等具体行为。
要让单元测试覆盖所有 catch 块中的边界异常处理，核心是**主动触发每种预期异常，并验证其处理逻辑是否按设计执行**——不是等异常“自然发生”，而是通过可控手段（如模拟、参数构造、依赖替换）让代码走进每个 catch 分支。
明确每个 catch 对应的异常来源和触发条件
先梳理被测方法中所有 try-catch 结构，逐个确认：
-
哪个位置抛出什么异常？ 是内部调用（如
service.doSomething()）、参数校验（如Objects.requireNonNull()）、还是 I/O/网络等外部依赖？ -
该异常是否被显式捕获？ 注意：子类异常可能被父类
catch捕获，需检查异常继承关系，避免误判“未覆盖”。 - catch 块里做了什么？ 是返回默认值、记录日志、转换异常、重试，还是修改状态？这些行为必须可断言（比如检查返回值、验证 mock 的 logger 是否被调用、断言字段变更）。
用 Mock 或 Stub 主动注入异常
对依赖外部组件（数据库、HTTP 客户端、文件系统等）的 catch，用 Mockito、MockitoExtension 或 TestContainers 等工具，让依赖在特定调用时抛出目标异常：
- 例如：mock 一个 service 方法，让它在第 2 次调用时抛出
NullPointerException，验证空指针的兜底逻辑； - 再 mock 同一方法，让它抛出
IOException，验证 IO 异常分支； - 注意区分 checked 和 unchecked 异常——前者编译强制处理，后者需确保运行时能到达，比如传入 null 或非法对象。
构造边界输入直接触发参数/校验异常
很多 catch 实际来自方法内部的显式 throw，比如：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
if (id <p>这类无需 mock 外部依赖，只需传入边界值即可覆盖：</p>
- 传
id = 0或id = -1触发IllegalArgumentException； - 传
null字符串触发NullPointerException（若未用@NonNull等注解提前拦截）； - 传超长字符串触发自定义长度校验异常。
验证 catch 行为，不止于“有没有抛异常”
覆盖 ≠ 执行了 catch 块，而是要证明它**正确执行了业务逻辑**。常见验证点：
-
返回值是否符合预期？ 比如 catch 后返回
Optional.empty()或默认对象，用assertThat(result).isEmpty()断言； - 状态是否更新？ 如设置失败标志、递增重试计数器，断言对应字段值；
-
日志是否记录？ 用
LogCaptor或 mock logger，验证日志级别和关键信息； -
是否抛出新异常？ 若 catch 中又 throw 了包装异常（如
throw new ServiceException(e)），用assertThrows<serviceexception>(...)</serviceexception>捕获并验证原因。
不复杂但容易忽略：每个 catch 都对应一个明确的测试用例，命名清晰（如 shouldReturnEmptyWhenDatabaseThrowsSQLException），失败时能一眼定位哪条异常路径没走通。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
