ES6 await为什么建议用try...catch捕获错误？

很多朋友可能在用 `async/await` 的时候，习惯性地把 `await` 语句写在 `try...catch` 块里，感觉这样很安全。确实，在 JavaScript 的世界里，处理异步操作的错误就像处理同步操作的错误一样重要，而 `try...catch` 又是我们最熟悉的错误处理机制。那为什么 `await` 特别“需要”我们用 `try...catch` 来管着它呢？咱们今天就来掰扯掰扯，保证不整那些虚头巴脑的 AI 式套话。

先回顾一下 `async/await` 的本质

在深入 `try...catch` 之前，我们得先明白 `async/await` 到底是什么玩意儿。简单来说，它就是对 Promise 的一种语法糖，让异步代码看起来更像同步代码。

`async` 函数：加了 `async` 关键字的函数，它总是会返回一个 Promise。即使你函数里没有 `return Promise.xxx`，它也会自动帮你包装成一个 Promise。
`await` 关键字：只能用在 `async` 函数里面。它会暂停 `async` 函数的执行，直到 `await` 后面的那个 Promise 状态变为 `fulfilled` (成功) 或者 `rejected` (失败)。
如果 Promise 成功了，`await` 就返回那个 Promise 的结果值。
如果 Promise 失败了，`await` 就会抛出一个错误，这个错误就是 Promise 被 `rejected` 时的原因。

关键点：`await` 抛出错误，就像同步代码一样

这里就是问题的核心所在。当一个 `await` 等待的 Promise 被 `rejected` 时，它不会像传统的 Promise 那样，只是默默地将错误传递给 `.catch()`，而是会像同步代码那样，直接抛出一个异常。

想象一下，如果你在同步代码里写：

```javascript
function doSomethingRisky() {
throw new Error("Something went wrong!");
}

try {
doSomethingRisky();
console.log("This won't be printed.");
} catch (error) {
console.error("Caught an error:", error.message);
}
```

这个 `doSomethingRisky()` 抛出的错误，不就是被 `try...catch` 捕获了吗？

`await` 行为非常相似。当 `await somePromise` 遇到 `somePromise` 被 `reject` 时，它内部的机制就是抛出这个拒绝的原因。

```javascript
async function fetchData() {
const response = await fetch('https://example.com/api/data'); // 如果这个 fetch 失败了 (例如网络问题)
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`); // 或者 fetch 本身可能抛错
}
const data = await response.json();
return data;
}

// 如果 fetchData 内部的 await 抛错了，会发生什么？
// 就像直接执行了 throw new Error(...)
```

所以，如果你在 `async` 函数中调用了一个可能会失败的 `await`，而你没有用 `try...catch` 来包裹它，那么这个错误就会被 未捕获。一个未捕获的错误在 JavaScript 中通常意味着什么？

1. 如果是浏览器环境：可能会在控制台显示一个红色错误信息，并且整个脚本的执行可能会中断（取决于浏览器的错误处理策略和脚本的其余部分）。
2. 如果是 Node.js 环境：通常会导致进程退出，或者触发 `uncaughtException` 事件，这是一个非常严重的信号，通常意味着应用状态可能不稳定。

为什么 `try...catch` 是“推荐”的捕获方式？

有了上面的铺垫，答案就呼之欲出了：

1. 统一的错误处理模型：`async/await` 旨在让异步代码更接近同步代码的编写和理解方式。同步代码的错误是用 `try...catch` 来处理的，`await` 的本质也是抛出异常，所以用 `try...catch` 来处理 `await` 的错误，完美地延续了这个模型，提供了一种统一的错误处理语法。你不再需要区分“同步错误”和“异步错误”的捕获方式，它们都归于 `try...catch`。

2. 更直观的代码结构：想象一下，如果你不用 `try...catch`，而是在 `async` 函数的末尾加一个 `.catch()`，就像这样：

```javascript
async function processData() {
const result1 = await step1();
const result2 = await step2(result1);
// ...
return finalResult;
}

processData()
.catch(error => {
console.error("An error occurred:", error);
});
```

这种方式，错误处理逻辑是写在函数定义之外的，而且你必须确保每一个调用 `processData()` 的地方都加上 `.catch()`，否则错误就会外泄。

而使用 `try...catch`：

```javascript
async function processDataWithCatch() {
try {
const result1 = await step1();
const result2 = await step2(result1);
// ...
return finalResult;
} catch (error) {
console.error("An error occurred:", error);
// 可以选择在这里返回一个默认值，或者抛出另一个错误，或者执行清理操作
return null; // 或者 throw error;
}
}

// 调用时，如果函数内部已经处理了错误，你可能就不需要再加 .catch() 了
// 或者你可以在调用处再次捕获，以防万一内部函数没有完全处理好
processDataWithCatch().then(result => {
if (result !== null) {
console.log("Success:", result);
} else {
console.log("Operation failed and handled internally.");
}
});
```

可以看到，`try...catch` 将错误处理逻辑内聚在了函数内部，使得函数更加自包含，也更容易管理错误发生时的行为（比如是直接终止函数返回，还是进行重试，还是清理资源）。

3. 细粒度错误控制：`try...catch` 允许你对不同的 `await` 操作进行更精细化的错误处理。你可以把每一个可能出错的 `await` 放在它自己的 `try...catch` 块里，或者将多个 `await` 放在一个 `try` 块里，然后根据错误类型在 `catch` 块中做不同的响应。

```javascript
async function complexOperation() {
let data1, data2;
try {
data1 = await fetchFirstResource();
} catch (err1) {
console.error("Failed to fetch first resource:", err1);
return { error: "Resource 1 unavailable" }; // 返回错误信息或默认值
}

try {
data2 = await fetchSecondResource(data1);
} catch (err2) {
console.error("Failed to fetch second resource:", err2);
return { error: "Resource 2 unavailable" };
}

// ... 处理 data1 和 data2
return { ... };
}
```

如果你不使用多个 `try...catch`，而是把所有 `await` 放在一个大 `try` 块里，一旦任何一个 `await` 抛错，整个 `catch` 块都会被执行，但你可能就难以区分是哪个步骤出了问题，除非你在 `catch` 块里通过错误对象的 `message` 或 `stack` 来判断。

4. 清理资源：在 `async` 函数中，你可能需要在操作完成后（无论成功还是失败）执行一些清理工作，比如关闭文件句柄、释放网络连接、清除定时器等。`finally` 块是 `try...catch` 的好搭档，它能确保无论 `try` 块中的代码是成功执行、抛出错误还是通过 `return` 退出，`finally` 块中的代码都会被执行。

```javascript
async function processFile(filePath) {
let fileHandle = null;
try {
fileHandle = await openFile(filePath); // 假设这是个异步操作
const content = await readFileContent(fileHandle);
await processContent(content);
return "Success";
} catch (error) {
console.error("An error occurred during file processing:", error);
throw error; // 重新抛出，让调用者知道失败了
} finally {
if (fileHandle) {
await closeFile(fileHandle); // 异步关闭文件
console.log("File handle closed.");
}
}
}
```

`finally` 块在处理异步资源清理时尤其重要，它保证了资源不会因为异步操作中的错误而泄露。

总结一下

`await` 本身会把 Promise 的 `rejected` 状态转换成一个抛出的异常。而 `try...catch` 是 JavaScript 中用来捕获和处理这种异常的标准方式。因此，将 `await` 语句包裹在 `try...catch` 中，是 JavaScript 社区中约定俗成且最自然、最健壮的错误处理模式，它保证了异步代码的健壮性、可读性和可维护性，并能让你更好地控制错误发生时的行为和执行清理操作。

这并不是说 `await` 必须写在 `try...catch` 里才能工作，而是说如果你不写，一旦 `await` 后面跟着的 Promise 被 `rejected`，错误就会像一个未经捕获的异常那样，对你的程序产生不良影响。`try...catch` 就是为了防止这种情况发生，让你能够优雅地处理这些潜在的失败。

那你为啥还要用await？