一聚教程网:一个值得你收藏的教程网站

最新下载

热门教程

怎么使用单个 try-catch 块内嵌多个类型校验优雅处理 await 多个未知接口的报错体系

时间:2026-06-18 09:52:54 编辑:袖梨 来源:一聚教程网

精准识别多 await 错误的关键在于错误类型可区分、校验逻辑可复用、异常流不打断正常流程:统一封装接口使错误带 source/code/retryable 字段,用 Promise.allSettled 或顺序 await + 错误标记定位失败环节,通过策略映射表解耦处理逻辑,并以结果容器实现部分失败继续执行。

用一个 try-catch 包住多个 await 调用,本身不难;但要让不同接口的错误被精准识别、分类处理、不互相干扰,关键在于「错误类型可区分」+「校验逻辑可复用」+「异常流不打断正常流程」。

统一包装接口,让错误带上下文标识

不要直接 await 原始 fetch 或 axios 请求,而是封装一层:返回 Promise 时,无论成功或失败,都确保错误对象包含 codesource(如 'user-api'、'order-api')和可选的 retryable 字段。

  • 例如封装函数 callApi(url, options),在 catch 中 throw new Error(`[user-api] Network failed: ${err.message}`),并附加属性:err.source = 'user-api'; err.code = 'NETWORK_ERROR';
  • 后端返回的业务错误(如 400/401/500)也统一转成带 source 和 code 的 Error 实例,避免靠 message 字符串匹配 —— 那种方式脆弱且难维护

在 catch 内按 source + code 分支处理,不靠 try-catch 嵌套堆叠

单个 try-catch 里 await 多个接口后,catch 拿到第一个抛出的错误。所以重点不是“捕获哪个”,而是“怎么知道错的是谁”。推荐用 try...catch + 可控的 Promise.allSettled 或顺序 await + 错误标记

  • 若必须并发(如三个接口无依赖),用 Promise.allSettled([p1, p2, p3]),结果数组里每个 item 都有 status: 'fulfilled' | 'rejected',可逐个 inspect,无需 try-catch 干预
  • 若需顺序执行(如第二步依赖第一步结果),就写 await p1; await p2; await p3;,并在 catch 里根据 error.source 判断是哪一步挂了,再做对应降级(比如 p1 失败则跳过 p2/p3,p2 失败则仍执行 p3)

定义错误策略映射表,解耦处理逻辑

把“什么错误 → 怎么响应”抽成配置对象,避免 catch 里写满 if-else:

  • 例如:const ERROR_HANDLERS = { 'user-api': { 'TOKEN_EXPIRED': handleTokenRefresh, 'NOT_FOUND': () => toast('用户不存在') } }
  • catch 中只需:if (err.source && ERROR_HANDLERS[err.source]?.[err.code]) { ERROR_HANDLERS[err.source][err.code](err); }
  • 这样新增接口或错误码,只改映射表,不碰主流程

允许部分失败继续执行,用结果容器收口

真正优雅的地方在于:不把“所有接口必须成功”当作前提。定义一个结果结构,比如:{ user: { data: null, error: null }, order: { data: null, error: null } }。每个 await 都包在独立 try-catch 里,失败时填 error,成功时填 data —— 最终汇总判断哪些可用、哪些要兜底。

  • 示例片段:
    const result = {};try { result.user = await callApi('/user'); } catch (e) { result.user = { error: e }; }try { result.order = await callApi('/order'); } catch (e) { result.order = { error: e }; }// 后续逻辑基于 result.user.data || result.user.error 来分支
  • 这样既保持单个 try-catch 结构简洁,又实现“尽力而为”,比全链路中断更符合真实业务场景

不复杂但容易忽略:错误的可识别性,比错误的捕获时机更重要。先让每个错误自带身份证,再用结构化方式读它,比层层嵌套 try-catch 更轻、更稳、更易测。

热门栏目