第三方sdk调用不强制抛出受检异常，但常见nullpointerexception等运行时异常；应聚焦可预期、可响应的失败场景，精准捕获特定异常（如alipayapiexception），避免笼统catch runtimeexception，并在catch中做日志、降级、重试或资源清理等有意义处理。
第三方 SDK 调用本身不强制抛出受检异常，但运行时异常（如 NullPointerException、IllegalArgumentException、IllegalStateException）很常见——比如传了 null 参数、配置未初始化、网络超时后返回空对象等。这类异常编译器不管，但你不能靠 try-catch 来“兜底修复逻辑错误”，而应聚焦在**可预期、可响应、有业务意义的失败场景**上。
只包裹真正需要捕获的调用点
不是所有 SDK 方法都要套 try-catch。重点覆盖以下几类：
- 涉及外部状态的操作：如
sdkClient.uploadFile(file)（文件可能损坏、路径无效） - 依赖网络或异步结果的方法：如
sdkService.fetchUserInfo(id)（返回 null 或抛IllegalStateException表示会话过期） - 解析类方法：如
JsonParser.fromJson(jsonStr, User.class)（格式错误时抛JsonParseException） - 明确文档标注“可能抛出运行时异常”的接口（哪怕它没在 signature 里写
throws）
catch 要具体，避免笼统捕获 RuntimeException
SDK 的运行时异常往往有特定子类，优先捕获它们，而不是写 catch (RuntimeException e)：
- 查 SDK 文档或源码，确认常用异常类型，例如：
AlipayApiException、WeChatPayException、OkHttpClient.TimeoutException - 若 SDK 未提供自定义异常，再考虑捕获其常见父类，如
IllegalArgumentException（参数非法）、IllegalStateException（状态不满足） - 绝对不要只写
catch (Exception e)或catch (Throwable t)且不做处理——这等于隐藏问题
catch 块里要做有意义的事，不是打印完就完
每一条 catch 都应回答三个问题：这个错我能不能理解？要不要通知用户？要不要降级或重试？
- 记录带上下文的日志：用 SLF4J 写
log.warn("Failed to call WeChat pay API for order {}, err: {}", orderId, e.getMessage(), e) - 转换为统一业务异常：如
throw new PaymentServiceException("WeChat payment unavailable", e)，让上层按策略处理 - 局部恢复：比如获取用户头像失败，返回默认头像 URL；配置加载异常，启用硬编码默认值
- 必要时重试：对幂等性明确的调用（如查询），可封装简单重试逻辑，但避免无限循环
别忽略资源和副作用清理
有些 SDK 调用会打开连接、申请临时内存或触发回调注册。即使发生异常，也要确保清理：
- 若 SDK 提供
close()、destroy()或cancel()方法，在finally或 try-with-resources 中调用（前提是它实现了AutoCloseable） - 避免在
finally里写return，它会覆盖 try/catch 中的返回值 - 注意：不要用 try-catch 掩盖本该提前校验的问题，比如调用前先判空、检查 ID 格式、确认 SDK 已初始化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
