精准捕获第三方异步sdk非标准异常的关键是判得准、拦得住、不逃逸；需聚焦三类高危入口，具体捕获自有或语义匹配异常，异步回调须独立防护，并辅以顶层兜底记录告警。
精准捕获第三方异步 SDK 的非标准异常，关键不在“包得全”，而在“判得准、拦得住、不逃逸”。这类 SDK（如支付、推送、OCR 等）通常用回调或 Promise 封装异步逻辑，但内部可能因配置缺失、状态错乱、空对象解引用等抛出 NullPointerException、IllegalStateException 或自定义运行时异常——它们不是受检异常，编译器不强制处理，却极易在调用链中突然崩溃。
只包裹明确暴露异常风险的调用点
不是每个 SDK 方法都要套 try-catch。聚焦三类高危入口：
- 带参数校验逻辑的方法：如
payService.pay(order, null)—— 传 null 可能直接触发IllegalArgumentException - 依赖初始化状态的操作：如
tracker.startSession()在 SDK 未 init 时调用，常抛IllegalStateException - 文档注明“可能抛运行时异常”的回调实现：例如微信支付的
onResp(BaseResp resp)中解析resp.errStr时未判空，引发NullPointerException
捕获要具体，拒绝裸 catch RuntimeException
第三方 SDK 通常提供自有异常类（如 AlipayApiException、WeChatPayException），优先捕获它们；若无，则按语义选父类，而非一锅端：
- ✅ 推荐写法：
catch (AlipayApiException e) { log.warn("支付宝网关返回错误", e); } - ✅ 次选写法：
catch (IllegalArgumentException e) { /* 参数非法，可降级或提示用户重填 */ } - ❌ 避免写法：
catch (RuntimeException e) { ... }—— 掩盖真实类型，无法区分是配置错还是空指针 - ❌ 绝对禁止：
catch (Exception e) { }或catch (Throwable t) { }—— 吞掉OutOfMemoryError等致命问题
异步回调里的 catch 必须自我防护
SDK 的回调（如 onSuccess、onFailure）常在子线程执行，其内部异常不会被外层 try-catch 捕获，会直接变成未处理异常。因此，每个回调块都需独立加防：
- 在
onSuccess中做 JSON 解析或 UI 更新前，先判空、再 try-catch：if (data != null) { try { parse(data); } catch (JsonParseException e) { log.error("解析响应失败", e); } } - 避免在 catch 块里发起新网络请求、操作 View 或调用未校验的 SDK 方法；真需要上报，必须嵌套：
reportError(e).catch(innerErr => log.warn("上报也失败了", innerErr)); - 推荐统一封装回调模板：
safeCallback(() -> doBusinessLogic(), e -> handleSdkError(e))，把防御逻辑收口
配合顶层兜底，形成双层防线
即使做了精准捕获，仍可能漏掉未覆盖的路径（如 SDK 内部线程池任务抛异常）。此时需架构级兜底，但仅用于记录与告警，不用于恢复：
- Android：设置
Thread.setDefaultUncaughtExceptionHandler，捕获子线程中未处理的 SDK 异常，记录堆栈 + 设备信息后上报 - Java 后端（Spring）：用
@ControllerAdvice拦@ExceptionHandler(ThirdPartyException.class)，返回标准错误码，同时打业务上下文（如订单号、traceId） - 切记：顶层 catch 不做降级或重试——那是业务层的事；它的唯一职责是“不让进程静默死掉，并留下可追溯线索”
