async/await 中自定义错误抛出

在 async/await 环境下处理自定义错误，核心思路其实很清晰：用 `throw` 抛出一个继承自 `Error` 的实例（或者至少是一个带有 `message` 和 `name` 属性的对象），然后在调用处用 `try/catch` 兜底捕获。这听起来简单，但实际项目中踩坑的点不少，下面展开聊聊几个关键环节。

开篇先明确一个基本原则：在 async/await 环境下自定义错误抛出，核心是用 `throw` 抛出一个继承自 `Error` 的实例（或至少具备 `message` 和 `name` 属性的对象），并在调用处用 `try/catch` 捕获处理。

定义可识别的自定义错误类

推荐继承原生 `Error` 类，这样堆栈信息、`instanceof` 判断和调试体验都能正常运作。具体做法是：构造函数中调用 `super(message)`，并设置 `this.name`；还可以添加额外属性（如 `code`、`status`）用于业务区分。有一点需要避免：只抛字符串或普通对象，那样后续很难统一拦截和做类型判断。 示例代码： ```javascript class ValidationError extends Error { constructor(message, field) { super(message); this.name = 'ValidationError'; this.code = 'VALIDATION_ERROR'; this.field = field; } } // 使用 async function createUser(data) { if (!data.email) { throw new ValidationError('邮箱不能为空', 'email'); } // ... } ```

在 await 后主动检查并抛出自定义错误

async 函数本身不会自动将 rejected Promise 转为自定义错误，所以需要显式判断响应或结果，再决定是否抛出。常见场景是调用第三方 API 后，检查 `response.status` 或返回体中的 `error` 字段。这里的关键是：不要依赖 `catch` 原始错误，而是根据业务逻辑“翻译”成领域错误。另外，尽量避免直接 `throw err`，那样可能丢失上下文信息，建议包装后再抛。 示例代码： ```javascript async function fetchUser(id) { const res = await fetch(`/api/users/${id}`); const data = await res.json(); if (!res.ok) { throw new ApiError(`请求失败: ${data.message || res.statusText}`, { status: res.status, code: data.code }); } if (!data.user) { throw new NotFoundError('用户不存在'); } return data.user; } ```

统一错误处理与中间层封装

在大型项目中，可以在请求函数或业务方法外层做标准化错误转换。比如封装一个 `safeAwait` 工具函数，自动将 Promise rejection 映射为自定义错误；或者在 API 客户端中统一拦截 HTTP 错误码，映射为 `NetworkError`、`AuthError` 等。这样做的好处是避免每个 `await` 都写重复的 `if (res.error)` 判断。 一个小技巧：用 `try/catch` 包裹单个 `await` 更清晰，不建议把多个 await 塞进一个 try 块里——否则一旦出错，很难准确定位是哪一步造成的。

在 catch 中精准识别和响应自定义错误

利用 `instanceof` 或 `error.name` 来区分错误类型，实现差异化处理。比如对 `ValidationError` 提示表单字段问题，对 `AuthError` 触发登出或跳转登录页，对未知错误兜底显示通用提示，并上报监控系统。 示例代码： ```javascript try { await submitForm(data); } catch (err) { if (err instanceof ValidationError) { showFieldError(err.field, err.message); } else if (err instanceof AuthError) { redirectToLogin(); } else { notifyUser('操作失败，请稍后重试'); reportError(err); } } ``` 这套流程在实际项目中非常实用，既能保证错误信息的完整性，又能让业务层清晰地处理不同场景。如果你正在搭建一个中型以上的前端应用，不妨试试这种模式。