Mockito 用 doThrow() 模拟自定义异常需区分运行时与检查异常：前者直接抛出，后者须匹配方法签名中的 throws；void 方法必须用 doThrow().when().method()，不可用 when().thenThrow()；测试中应结合业务验证异常触发的降级、码值等行为。
用 Mockito 的 doThrow() 模拟自定义异常，核心是确保异常类型匹配、抛出时机可控，并且不触发真实方法逻辑。
确认自定义异常是运行时异常还是检查异常
Mockito 对两类异常的处理方式不同：
- 如果是 RuntimeException 及其子类（如 IllegalArgumentException）：直接抛出，无需声明或 try-catch
- 如果是 检查异常（checked exception，如 IOException）：必须与被 mock 方法签名中声明的 throws 类型一致，否则编译报错
例如，若 service 方法声明了 throws BusinessException，那 BusinessException 必须是 checked exception（继承自 Exception 但非 RuntimeException），且在方法签名中显式写出。
正确写法：doThrow().when().method() 链式调用
不要用 when(...).thenThrow() 去 mock void 方法 —— 这会抛出 UnfinishedStubbingException。对 void 方法，必须用 doThrow() 开头：
立即学习“Java免费学习笔记（深入）”；
// ✅ 正确：mock void 方法抛异常
doThrow(new BusinessException("订单不存在")).when(orderService).cancelOrder(eq("123"));
// ✅ 正确：mock 返回值方法抛异常（也可用 when...thenThrow）
doThrow(new BusinessException("库存不足")).when(inventoryService).deductStock(anyString(), anyInt());
// ❌ 错误：void 方法不能用 when().thenThrow()
when(orderService.cancelOrder("123")).thenThrow(new BusinessException("xxx")); // 编译通过但运行时报错
结合业务场景模拟典型故障路径
真实测试中，要让异常触发后续的业务判断（比如事务回滚、降级逻辑、错误码封装）：
- 在测试方法中调用被测服务，捕获预期异常或验证响应结果
- 用
@Test(expected = BusinessException.class)或assertThrows()断言异常类型 - 如果业务方法 catch 了该异常并返回友好提示，就验证返回对象的 code/message 字段
示例：
@Test
void should_return_error_when_cancel_order_fails() {
doThrow(new BusinessException("支付已退款，不可取消")).when(orderService).cancelOrder("ORD-001");
Result result = orderFacade.cancel("ORD-001");
assertThat(result.getCode()).isEqualTo("BUSINESS_ERROR");
assertThat(result.getMsg()).contains("不可取消");
}
注意异常构造与 equals 判断一致性
如果测试中需要验证抛出的异常是否“等于”某个实例（比如用 assertThrows 后再检查 message），建议自定义异常重写 equals() 和 hashCode()，或至少保证 message、code 等关键字段可比对。否则仅靠 instanceof 可能不够精准。
更稳妥的做法是：在 assertThrows 中直接断言 message 内容或业务错误码：
BusinessException ex = assertThrows(BusinessException.class, () -> service.process("invalid"));
assertEquals("参数非法", ex.getMessage());
assertEquals("PARAM_INVALID", ex.getErrorCode());
