验证异常分支捕获覆盖率需确保每条可能抛错路径被执行且错误处理逻辑被触发：覆盖throw/reject/依赖失败等源头，验证catch/finally/回调真实运行，区分错误类型与边界场景，并用覆盖率工具定位未执行的异常处理代码。
要验证异常分支的捕获覆盖率，核心不是“测有没有 try-catch”，而是确保每一条可能抛错的路径都被执行，并且对应的错误处理逻辑（如 catch、finally、throw new Error、错误回调）确实被触发和覆盖。
覆盖所有可抛错的源头
异常分支始于抛错点，必须让每个 throw、reject、同步/异步错误都实际发生：
- 构造函数中参数校验失败：例如 new Calculator(-1) 应抛出 Error，测试需用
expect(() => new Calculator(-1)).toThrow() - 方法内显式 throw：如
add(null, 2)抛错，需单独写用例触发该路径 - 异步 reject：对 async 方法，用
await expect(promise).rejects.toThrow(...)或catch回调断言 - 外部依赖失败：用
jest.mock模拟 fetch 返回 500，或 mock fs.readFile 抛出 ENOENT
验证错误处理逻辑本身被执行
仅捕获错误不够，要确认 catch 块、错误回调、fallback 行为等真实运行过：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在 catch 块里加一句
console.log('handled')，再检查覆盖率报告中该行是否点亮 - 对带副作用的错误处理（如上报 Sentry、重置状态），在测试中 mock 对应函数并
expect(mockFn).toHaveBeenCalled() - finally 中的清理逻辑（如关闭连接、释放资源）需单独设计用例——例如先让主逻辑成功，再让其失败，两次都应进入 finally
区分不同错误类型与边界场景
同一段错误处理代码，面对不同 error 实例可能走不同分支：
立即学习“Java免费学习笔记（深入）”；
- 用
instanceof或error.name分支时，需分别提供 TypeError、NetworkError、自定义 ValidationError 等实例 - 错误消息含关键词时（如
if (err.message.includes('timeout'))），测试中要构造对应 message 的 error - 空值、超长输入、并发冲突等边界条件，常是隐藏异常源，例如
JSON.parse(undefined)或Array.from({ length: Infinity })
借助覆盖率工具定位盲区
Jest + Istanbul 默认统计语句和分支，但异常路径容易被忽略：
- 确保
collectCoverageFrom包含含 try/catch 的文件，且未 exclude 错误处理模块 - 打开 HTML 覆盖率报告，重点查看 catch 块首行、throw 行、re-throw 行 是否标绿；灰色说明从未执行
- 对 Promise 链中的 .catch()，注意它属于独立语句，需确保 promise 真正 reject —— 不要用
Promise.resolve().catch(...)这种永不会进 catch 的写法
