精准捕获第三方异步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 不做降级或重试——那是业务层的事；它的唯一职责是“不让进程静默死掉，并留下可追溯线索”