如何在嵌套异步函数调用中正确传递和捕获错误

详解 Ja vaScript 嵌套异步函数中的错误传播：为何你的 try/catch 有时会“失灵”？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在基于 Office JS API（比如 `Excel.run`）开发插件时，很多开发者习惯用 `async/await` 来组织清晰的业务逻辑，并理所当然地认为，最外层的那个 `try/catch` 能一网打尽所有深层异步操作里冒出来的错误。但现实往往很骨感——错误有时会像泥鳅一样溜走，既不中断流程，也没被捕获，最后在控制台留下一个孤零零的“Uncaught Error”。这其实不是 Ja vaScript 的 Bug，而是对其异步错误传播模型的一个典型误解。

问题的根源：错误抛错了地方

核心症结在于：在 `setTimeout` 回调里 `throw` 错误，这个动作发生在一个全新的、与当前 Promise 链完全脱钩的宏任务上下文中。它不会自动关联到任何 Promise 的 rejection 状态。

举个例子，下面这个 `fail()` 函数看起来返回了一个“会失败的异步操作”，但实际上它返回的是一个立即就 `resolve` 的 Promise。那个 `setTimeout` 里的 `throw`，只会触发全局的未捕获异常，跟外层的 `await` 和 `try/catch` 毫无关系：

async function fail(message, delay) {
  setTimeout(() => {
    throw new Error(message); // ❌ 错误在这里抛出，但和哪个 Promise 有关？没有。
  }, delay);
  // 函数体瞬间执行完毕，返回的 Promise 已经 resolve → 外层 await 等了个寂寞，无异常可抓
}

让错误重回正轨：三个必须遵守的原则

想让错误乖乖地沿着 `async/await` 的链条向上传播，必须确保：

1. 错误得在 Promise 的执行器（executor）里，或者直接在 `async` 函数体里同步抛出；
2. 所有异步操作（比如延迟）都得通过 `await` 来驱动，让控制流始终待在 Promise 链内部；
3. 包装函数（比如 `run`）必须 `return f()`，而不能只是调用 `f()`。否则，它返回的 Promise 就和 `f()` 的执行结果脱钩了。

✅ 正确的实现方式

先来看一个正确的工具函数和改造后的 `fail` 函数：

// ✅ 正确的延迟工具：返回一个可以 await 的 Promise
const delay = (ms) => new Promise(resolve => setTimeout(resolve, ms));

async function fail(message, delayMs) {
  await delay(delayMs); // ⚠️ 先等待，再抛错
  throw new Error(message); // ✅ 在 async 函数体内抛出 → 自动转为 Promise rejection
}

async function success(message, delayMs) {
  await delay(delayMs); // ✅ 必须 await，否则延迟不生效
  console.log(message);
}

async function run(f) {
   return f(); // ✅ 关键一步！把 f() 返回的 Promise 原封不动地透传出去
}

接下来是业务逻辑层。注意看，当 `failA` 为真时，`doA` 函数中 `await fail(...)` 之后的 `console.log(“Done A”)` 是不会执行的，因为错误已经导致 Promise 被 reject，控制流直接跳转：

async function doA() {
  console.log("Inside A");
  if (failA) {
    console.log("Failing A");
    await fail("Error A", 1000); // ✅ await 使得 rejection 能被上层捕获
  } else {
    await success("Success A", 1000);
  }
  console.log("Done A"); // ❌ 这一行不会执行（如果 failA 为 true）
}
// doB 函数结构同理...

最后，在入口函数 `main` 中，我们用 `try/catch` 来统一接管：

async function main() {
  try {
    await run(async () => {
      console.log("Start main");
      await doA(); // ❌ 如果这里 reject 了，后续代码会完全被跳过
      console.log("Between A and B"); // ❌ 这一行不会打印
      await doB();
      console.log("Finished");
    });
  } catch (error) {
    console.log("ERROR: " + error.message); // ✅ 稳定捕获到 “Error A”
  }
}

? 关键注意事项与最佳实践

• 永远不要在 setTimeout/setInterval 的回调里直接 throw —— 这相当于在一个全新的事件循环任务中抛错，和你的 Promise 上下文彻底失联；
• 所有异步副作用（包括延迟、网络请求、API调用）都应该封装成返回 Promise 的函数，并且显式地使用 await；
• 高阶包装函数（比如 Excel.run 或你自己写的 run 函数）必须 return f()，这是错误能否向上冒泡的“总闸门”；
• 在实际的 Office JS 场景里，`Excel.run` 本身已经正确实现了 Promise 链的透传。所以，开发者只需要确保传入的回调函数内部逻辑符合上面的规范就行。

只要遵循以上原则，就能实现预期的错误中断行为：一旦 `doA()` 抛出错误，`doB()` 会被直接跳过，控制权立即移交到 `main()` 的 `catch` 块中。这样一来，插件的健壮性和用户体验的一致性就有了坚实的保障。