应封装第三方异常以提升代码可维护性。1. 定义自定义异常如ServiceCallException，捕获IOException等底层异常并包装，保留cause信息；2. 通过ExternalApiExecutor工具类统一转换异常，减少重复try-catch；3. 封装时补充订单ID、URL等业务上下文便于排查，避免泄露敏感信息；4. 区分可重试（如超时）与不可重试异常（如401），自定义异常可添加isRetryable方法。最终实现异常隔离，降低系统耦合，提升错误可读性和维护性。
在Java开发中，调用第三方库时经常遇到它们抛出的异常。这些异常可能是检查型（checked）也可能是非检查型（unchecked），直接暴露或层层上抛会影响代码可维护性和调用方体验。要优雅处理，核心是封装、转换、隔离和提供上下文信息。
1. 封装异常，避免暴露底层细节
第三方库的异常类型通常与业务无关，直接抛给上层会增加耦合。应将其封装为自定义异常，屏蔽实现细节。
例如，使用Apache HttpClient时可能抛出IOException或ClientProtocolException，可以统一转为服务级异常：
- 定义一个业务相关的异常类，如ServiceCallException
- 捕获原始异常，包装后抛出，保留原异常作为cause
try {
HttpResponse response = httpClient.execute(request);
} catch (IOException | ClientProtocolException e) {
throw new ServiceCallException("调用用户服务失败", e);
}
2. 统一异常转换，减少重复代码
多个地方调用同一类第三方服务时，重复写try-catch会冗余。可通过模板方法或工具类集中处理。
立即学习“Java免费学习笔记（深入）”；
比如创建一个ExternalApiExecutor工具：
- 接收一个函数式接口作为执行逻辑
- 内部统一捕获特定异常并转换
- 调用方只需关注业务逻辑
return ExternalApiExecutor.call(() -> {
return thirdPartyService.fetchData(param);
});
3. 提供清晰的错误上下文
原始异常往往缺少业务信息。封装时应补充关键参数，便于排查问题。
建议做法：
log.error("调用支付网关失败，订单ID={},金额={}，目标地址: {}",
orderId, amount, url, e);
throw new PaymentException("支付请求失败");
4. 区分异常类型，决定是否重试
不是所有异常都值得重试。网络超时可尝试恢复，而认证失败则不应重复调用。
- 对可恢复异常（如SocketTimeoutException）标记为可重试
- 对不可恢复的（如401、404）直接终止流程
- 可在自定义异常中添加isRetryable()方法辅助判断
基本上就这些。关键是不让第三方异常穿透到业务层，保持系统边界清晰，出错时也能快速定位问题。处理得当的话，更换底层库时上层几乎不用改代码。
