错误处理

是什么，为什么存在

错误处理是一套控制流协议，用于处理无法产生正常结果的操作。函数不再返回， 而是抛出一个值；JavaScript 随即把控制权转移给最近的 catch。如果当前调用链中 没有处理器，异常就会到达宿主环境。

Error 对象是约定俗成的失败值。它的标准数据包括 name、message 和可选的 cause；运行时通常还会提供非标准的 stack，供诊断使用。TypeError、 RangeError、ReferenceError 和 SyntaxError 等内置子类区分了宽泛的语言级 失败类别。

JavaScript 在技术上允许用 throw 抛出任何值。因此，在检查之前，必须把 catch 绑定视为未知值。应用代码仍应约定抛出 Error，因为它以工具和人都熟悉的结构 携带类型、上下文以及通常可用的堆栈跟踪（stack trace）。

失败操作与普通分支

当操作无法履行契约，而直接调用方又未必知道恢复策略时，应使用异常。配置语法 无效、不变量被破坏或依赖调用失败，都符合这个模型。对于「没有搜索结果」这类正常 且预期内的备选结果，使用 undefined、null 或显式结果对象通常更清楚。

两者的区别取决于 API 契约，而不是事件发生的频率。同一个记录缺失，在某一层可以是 预期的查询结果，在另一层却可能意味着必要条件失败。应在拥有策略的边界转换这两种 含义，不要让每个底层函数都决定如何通知用户。

每个捕获边界的四项决策

有效的处理器会明确作出一项决策：用契约规定的值恢复，按有界策略重试，在保留原因的 同时转换失败，或先完成本地工作再重新抛出。只写日志不等于恢复。捕获错误后继续使用 临时编造的值，会悄悄改变函数契约。

在策略允许的范围内，try 区域应尽量小。过宽的代码块可能把后续代码中的编程错误， 误判成预期的输入或依赖失败。范围收窄后，处理器究竟在描述哪个操作也会更清楚。

工作原理

抛出与栈展开

执行 throw value 会产生突然完成（abrupt completion）。JavaScript 停止执行当前 代码块中的剩余语句，并沿活跃调用向外寻找 catch。这种 错误传播（error propagation） 会保留抛出的原值，不会自动把字符串、对象或其他值转换为 Error 实例。

找到处理器后，它的绑定会接收被抛出的原值。处理器正常结束时，执行从整个 try...catch...finally 语句之后继续。如果处理器重新抛出，搜索就会带着新值或 原值继续向外进行。

图中有两个入口会进入失败处理。同步抛出会立即展开当前调用。被拒绝的 Promise 则通过 自身的敲定状态报告失败，之后的 await 或拒绝处理器才是恢复普通异常式控制流的 位置。

try、catch 与 finally 的职责

try 块包含受同一项处理策略约束的操作。存在 finally 时可以省略 catch；不需要 错误值时，也可以省略 catch 参数。JavaScript 没有条件捕获的专用语法，应先检查值， 处理自己负责的情况，再重新抛出其他情况。

无论前面的路径是正常结束、返回、跳出循环还是抛出，finally 都会在控制权离开整个 结构前运行。这里适合释放资源或恢复局部状态。但它不能保证在进程关闭时运行；强制 终止可能让 JavaScript 没有机会继续执行代码。

finally 内的 return 或 throw 会替换已经在进行的完成结果。因此，它既可能丢掉 有效返回值，也可能丢掉正在传播的异常。清理代码通常应正常结束，让原来的结果继续 存在。

Promise 拒绝是另一条通道

async 函数总会返回 Promise。函数体任意位置的抛出都会拒绝该 Promise，包括第一个 await 之前的抛出。调用方要么在 try...catch 中等待 Promise，要么把它返回给其他 所有者，要么附加拒绝处理器。

在 try 块中调用异步函数却不使用 await，不会把它稍后的拒绝连接到这个 catch。 调用本身成功产生 Promise，随后同步控制流离开代码块，Promise 才完成敲定。缺失的 所有权通常会表现为未处理的拒绝，而不是预期的恢复路径。

Promise 链遵循同一原则。.then() 回调中的抛出会拒绝该 .then() 返回的 Promise， 而 .catch(handler) 是拒绝处理器的简写。如果处理器正常返回，下一个 Promise 会用其 返回值兑现；要让链保持失败，处理器必须抛出或返回被拒绝的 Promise。

错误应跨越所有权边界

底层代码通常应附加它知道的事实，再由调用方决定展示方式。解析器可以指出无效字段； HTTP 处理器则可以把该领域错误映射为状态码和公开消息。混合这两项决策，会让错误类 绑定到某一种界面，也使同一领域操作难以复用。

启动异步工作的边界也拥有它的拒绝。应等待它、返回它、把它放进显式管理的任务组， 或附加终结处理器来记录有意采用的即发即弃策略。只创建一个 Promise 并不构成所有权 策略。

示例

在输入边界验证

这个边界区分两种情况：JSON 本身损坏，以及对象有效但业务字段无效。它会处理两个已知 情况，并重新抛出策略范围之外的错误。自定义类为调用方提供稳定的类型和字段，无需解析 错误消息。

JSON.parse() 抛出的是运行时 SyntaxError，所以这个处理器能够观察到它。另一种情况是 语法错误导致外围脚本根本无法解析；此时脚本完全不会运行，其中的 try 语句自然也无法 处理解析失败。

添加操作上下文，同时保留原因

底层知道连接已关闭，订单层知道失败的是哪个操作。 错误包装（error wrapping） 会同时记录这两项事实。把捕获值作为 cause 传入，可以保留诊断信息，又不必把不稳定的 底层措辞塞进公开消息。

class OrderLoadError extends Error {
  constructor(orderId, options) {
    super(`Could not load order ${orderId}`, options);
    this.name = "OrderLoadError";
    this.orderId = orderId;
  }
}

async function requestOrder() {
  throw new TypeError("connection closed");
}

async function loadOrder(orderId) {
  try {
    return await requestOrder(orderId);
  } catch (cause) {
    throw new OrderLoadError(orderId, { cause });
  }
}

async function main() {
  try {
    await loadOrder("A-17");
  } catch (error) {
    console.log(`${error.name}: ${error.message}`);
    console.log(`cause: ${error.cause.name}: ${error.cause.message}`);
  }
}

main().catch(console.error);

OrderLoadError: Could not load order A-17
cause: TypeError: connection closed

loadOrder() 内的 await 很重要。如果在 try 中直接返回 requestOrder(orderId)， 函数会在返回的 Promise 拒绝前离开，因此本地 catch 无法包装失败。边界必须转换拒绝时， return await 有明确用途。

释放资源，同时保留失败

代码在受保护操作之前获取资源，并通过 finally 在该操作的所有退出路径上释放锁。 调用方仍会收到原始写入错误。实际输出也证明，清理发生在外层处理器恢复执行之前。

class Lock {
  constructor(key) {
    this.key = key;
    console.log(`acquired: ${key}`);
  }

  release() {
    console.log(`released: ${this.key}`);
  }
}

async function saveInvoice(invoiceId) {
  const lock = new Lock(`invoice:${invoiceId}`);
  try {
    throw new Error("write failed");
  } finally {
    lock.release();
  }
}

async function main() {
  try {
    await saveInvoice(42);
  } catch (error) {
    console.log(`handled: ${error.message}`);
  }
}

main().catch(console.error);

acquired: invoice:42
released: invoice:42
handled: write failed

如果受保护操作与清理都抛出错误，普通 finally 语义会暴露清理错误，并替换先前的错误。 两项失败都很重要时，清理层必须有意记录或聚合它们；JavaScript 不会自动完成组合。

报告批处理中的每项结果

Promise.allSettled() 会等待每个输入兑现或拒绝，并按输入顺序保留结果。代码先保留成功 任务的名称，再把收集到的拒绝原因转换为一个 聚合错误（aggregate error） 。 这种策略适合所有尝试都应结束，但整个批次仍必须报告失败的场景。

const tasks = [
  ["catalog", () => Promise.resolve("updated")],
  ["inventory", () => Promise.reject(new Error("inventory unavailable"))],
  ["receipt", () => Promise.resolve("sent")],
];

async function runBatch(entries) {
  const settled = await Promise.allSettled(
    entries.map(([, run]) => run()),
  );
  const fulfilled = [];
  const failures = [];

  settled.forEach((result, index) => {
    const [name] = entries[index];
    if (result.status === "fulfilled") {
      fulfilled.push(name);
    } else {
      failures.push(result.reason);
    }
  });

  console.log(`fulfilled: ${fulfilled.join(",")}`);
  if (failures.length > 0) {
    throw new AggregateError(failures, `${failures.length} task failed`);
  }
}

runBatch(tasks).catch((error) => {
  console.log(`${error.name}: ${error.message}`);
  console.log(`causes: ${error.errors.map((item) => item.message).join(",")}`);
});

fulfilled: catalog,receipt
AggregateError: 1 task failed
causes: inventory unavailable

每个拒绝原因仍然可以是任意 JavaScript 值。生产环境中的聚合逻辑应先规范化或检查原因， 再读取 .message，尤其是在任务调用了批处理所有者无法控制的代码时。

陷阱

吞掉失败

修复： 只有回退值属于函数书面契约时才进行恢复。其他情况下，应添加有用上下文后 重新抛出，或在完成必要的本地报告后重新抛出原始错误。

假定每个捕获值都是 Error

修复： 使用 Error 属性前，先通过 error instanceof Error 收窄该值。在外部边界， 可以把非错误值统一规范化为一个新的 Error，并让它的 cause 保留原值。

省略 await 而丢失拒绝

修复： 如果当前作用域拥有处理策略，就使用 await；否则返回 Promise，把所有权交给 调用方。对于有意创建的后台工作，应附加终结拒绝处理器，并记录关闭、取消和可观测性行为。

从 finally 返回

修复： 让 finally 专注于清理并正常结束。如果清理本身可能失败，应定义哪项失败优先， 或创建能同时保留两者的聚合错误，不要依赖偶然的优先级。

把 Promise.all() 当作取消机制

修复： 应显式选择失败拓扑。每项结果都重要时使用 allSettled()；某项失败后应停止 其他工作时，向可取消操作传入共享取消信号，同时仍应等待敲定，让清理拥有明确的负责人。

延伸阅读

• ECMAScript 语言规范：try 语句
• MDN：Error
• MDN：try...catch
• MDN：Promise.allSettled()
• MDN：AggregateError
• Node.js 24：错误