12 错误的旅程:从 throw 到全局兜底Copy Anchor Link

这一章讲什么Copy Anchor Link

错误对象造好了、信息也全,但送不到能用它的地方,一切都白搭。 这一章跟踪一次 throw 的完整旅程:控制流怎么被打断、调用栈怎么逐帧拆除、 catch 该放在哪(答案是「按含义划分的边界」)、finally 这个老实人怎么会变成内鬼; 然后是本章的重头:异步边界——setTimeout 这类「晚点再跑」的机制 会拆掉整个调用栈,try-catch 在它面前失效,栈里再也查不到「是谁排的这个任务」。 最后看兜底的最后一道防线:全局错误处理器,以及为什么它只配当安全网。

顶层全景:一次 throw 的三种结局Copy Anchor Link

  throw:正常执行立即停止,引擎沿调用栈向上逐帧拆,找 catch
     │
     ├─ ① 某个 try-catch 接住了 → 在这里做恢复/记录决策,传播终止
     │      (接住了还可以用 cause 包好再抛,送往上一层边界)
     │
     ├─ ② 一路拆到栈底没人接 → 交给宿主:浏览器打一条控制台日志;
     │      Node.js 终结进程(uncaughtException 事件,视为致命)
     │
     └─ ③ 错误发生在异步回调里 → 调用栈早已消失,①②都够不着
            → 只能落到全局错误事件;恢复上下文全丢,栈只剩定时器内部帧

  图说:三个结局里,只有①给了你完整的恢复上下文和调试现场;
        这一章的全部实践建议,就是「尽量让错误在①里被接住」。

核心原理Copy Anchor Link

3.1 throw 是劫机,不是创建Copy Anchor Link

先纠正一个常见混淆:throw 不创建错误——new Error(...) 才创建。 throw 做的是劫持控制流:语句执行到它的那一刻,正常流程立即停止, 引擎开始沿着调用栈往回走,一层一层拆,找能处理异常的 catch; 每拆一层,那层函数剩下的代码全部不再执行¹。

书里给的最小示例,状态清清楚楚²:

function level3() { throw new Error("Origin point"); }
function level2() { level3(); console.log("Never executed"); }
function level1() { level2(); console.log("Never executed"); }
level1();   // 报错:Origin point —— 两层 console.log 都没跑

栈的拆除是「逐帧上卷」(unwind):level3 抛出 → level3 帧拆 → level2 帧拆(它的 console.log 没执行)→ level1 帧拆 → 到顶层还没有 catch → 报告宿主:未捕获³。catch 一旦出现,拆除就停在那里, 「已捕获」成立,传播终止⁴。

3.2 catch 放哪:语义边界是唯一正解Copy Anchor Link

catch 的位置有个天然张力,书里摆得很明白⁵:

• 放太深(离 throw 近):本地调试信息全在,但你往往没有 做恢复决策的信息——底下某层数据库查询失败,它自己不知道该提交还是回滚;
• 放太高(接近顶层):恢复决策的信息够了,但「具体哪一步、为什么失败」 的细节已经在层层上传中磨没了。

正解:放在语义边界(semantic boundary)上——你既有足够的信息做恢复、 又能为上层保留有用细节的点位⁶。书里列了四类⁷:

主线例子:数据库事务。 三条查询加一次提交,包在一个 try 里:

function updateUserProfile(userId, changes) {
  const tx = db.beginTransaction();
  try {
    const user = tx.query('SELECT ...', userId);      // 可能失败
    tx.query('UPDATE ...', userId, changes);          // 可能失败
    tx.query('INSERT INTO audit_log ...', userId);    // 可能失败
    tx.commit();
  } catch (e) {
    tx.rollback();                                     // 恢复决策:回滚
    throw new Error('Profile update failed', { cause: e });  // 包好,送上边界
  }
}

为什么不每条查询各自包 try-catch?单条查询失败时你不知道该不该回滚—— 那要到「整组操作」这一层才知道;也不该把 catch 放到应用顶层——那时你已经丢了 「是哪条查询失败」的细节。事务边界本身就是那个刚刚好的位置: 在这里回滚是合法的,用 cause 把原始错误包进新错误往上送, 上层边界拿到的是干净的恢复语义 + 完整的调试链⁸。

3.3 finally:永远会跑,也会永远坑你Copy Anchor Link

finally 块是 try-catch 的收尾员:无论有没有抛错、有没有被接住, 它都执行——这是它做资源清理(关连接、释放文件)的价值所在⁹。 但书里给这个老实人揭了底:finally 里的代码可以吞掉或替换正在传播的 错误——这是规范明文规定的行为,不是 bug¹⁰:

function suppressed() {
  try { throw new Error("This disappears"); }
  finally { return "Success!"; }     // return 劫持:错误被吞,函数正常返回!
}
function replaced() {
  try { throw new Error("This disappears"); }
  finally { throw new Error("This replaces it"); }   // 新错误顶掉旧的
}

原错误对象其实还活着,栈也抓了,消息也设了——但传播途中被 finally 截胡,一切白搭,恢复与调试两头的信息全部作废¹¹。 作者的评价:这是规范有意给开发者的最大控制权,但对不小心的人, 它是上了膛的脚枪(footgun)¹²。纪律只有一条:finally 里只做清理, 绝不 return、绝不 throw。

3.4 用 throw 当流程控制?绝对不行Copy Anchor Link

书里单独立了块牌子:「绝不要用 throw 做控制流」¹³。 反模式长这样:在 forEach 回调里 throw item,外层 try-catch 接住当 返回值用——把异常机制当 goto 使¹⁴。

历史上这招是真性能的灾难(V8 时代早期优化不了 try-catch); 如今引擎能优化了,它仍然是烂代码:性能账另算,可读性和可调试性已经完了。 该用 return/break/continue 的地方就用它们; throw/try/catch 只留给真正的异常¹⁵。

3.5 异步边界:调用栈消失的地方Copy Anchor Link

本章重头。01 章建立的事实在这里兑现:setTimeout、process.nextTick、 事件监听、Promise 回调——所有「晚点再跑」的机制,都切断了调用栈。 看一个看似无害的例子¹⁶:

function processData(data) {
  setTimeout(() => { throw new Error("Processing failed"); }, 100);
}
try {
  processData(data);
} catch (e) {
  console.log("Never catches it");   // 永远打不出来
}

外层的 try-catch 完全够不着这个错误。原因在时序:100 毫秒后回调 真正执行时,当初那个包含 try-catch 的调用栈早已跑完、消失; 错误被抛在一个全新的栈里,这个新栈和当初调度它的代码没有任何连接¹⁷。 错误没有走向「被接住」或「交给宿主」的正常路径,而是直接砸进全局。

它同时砸断了恢复和调试两头¹⁸:

• 恢复侧:边界断了。调度异步工作的代码没法用 try-catch 捕获回调里的失败; 你必须有完全不同的机制跨这个边界传错误(Promise 链就是答案之一—— 但 01 章说过,microtask 队列的事,这本书承诺的第 8 章还没写)。
• 调试侧:栈残缺。抛错瞬间的栈里只有回调内部和定时器实现, 没有任何「是 processData 调度了我」的信息¹⁹:

  Error: Processing failed
    at Timeout._onTimeout (file.js:3:11)
    at listOnTimeout (node:internal/timers:573:17)
    at process.processTimers (node:internal/timers:514:7)

三行全是定时器内部机制,你的业务函数一个字没有²⁰。

补丁的存在与极限:现代引擎有「async stack traces」(异步栈), 尝试重建「await 链、Promise 链」来补全历史;但重建的栈不完整、有性能代价、 且根本不解决恢复问题——最致命的是,它对 setTimeout 这类 Web API 完全无效,因为引擎根本不知道宿主调度了它²¹。

书里给这条边界下的判词值得记住:异步边界从根本上把错误和它的来源拆开了; 任何「把工作排晚点」的 API 都跨过了这条线,你在 01 章学的所有调度机制 都是越境点²²。

3.6 全局处理器:最后一道防线,不是策略Copy Anchor Link

try-catch 够不着的错误总得有个去处:引擎找遍栈无果,会把错误交给宿主, 宿主是绝对最后一道防线²³。两边的形态:

浏览器:window.addEventListener('error', ...)——能接到同步和异步代码里 所有漏网之鱼;回调里拿得到错误对象、出错的文件名和行号, event.preventDefault() 还能阻止默认的报错行为²⁴。

Node.js:process.on('uncaughtException', ...)。关键差异: 在 Node 里未捕获异常是致命的——进程已处于未定义状态,不应继续正常工作; 没有这个处理器,进程会打日志然后退出²⁵。

两个用途都是真的:记日志、报监控。但两边的能力都有限,书里点名了²⁶:

• 对恢复:全局处理器离现场太远。错误到这时,你不知道当时在做什么操作、 涉及什么数据、系统处于什么状态、该用什么恢复策略——能做的只有记录,然后祈祷;
• 对调试:同步错误的栈虽完整,但已经穿过不知多少层抽象; 异步错误的栈照旧残缺。全局处理器是「错误被记录的地方」, 不是「错误被理解的地方」²⁷。

所以定调:真正的解法是别让错误走到这一步——在语义边界上接住它们; 全局处理器是安全网,用来兜「错误处理本身的失误」。 如果错误经常落到全局处理器,信号很明确:边界的错误处理缺位了²⁸。

3.1b 旅程的逐帧拆解:三层函数怎么被拆掉的Copy Anchor Link

3.1 节给了最小示例,这里把「逐帧拆除」走成慢动作²⁹:

  栈(自下而上):        [level1] [level2] [level3]
  level3 抛出 ──────────────────────────────→ 先拆 level3 自己:
                                                它剩下的语句作废
                        [level1] [level2]      → 拆 level2:
                                                它的 console.log("Never executed") 不跑
               [level1]                        → 拆 level1:
                                                它的 console.log("Never executed") 也不跑
  栈空,无 catch ──────────────────────────────→ 报告宿主:uncaught

每一步拆除做两件事:丢弃该层剩余的字节码执行,释放该层的栈帧。 所以 throw 的代价不只是「造了个 Error 对象」,还有沿途每一层的 「善后」——层数越深,拆除越贵;这也是为什么「用 throw 当流程控制」 (3.4 节)既难看又真贵:它在为「正常的返回路径」付「异常的拆除费」³⁰。

catch 块的位置决定了拆除在哪一层停。同一个错误,被 middle 接住与被 outer 接住,对系统的意义完全不同:middle 接住,middle 以上的层 (包括 outer 的 try)都感知不到任何事;outer 接住, 中间所有层的本地状态已经全部灰飞烟灭——这就是为什么「放哪一层」 是个有实质后果的决策,而不是风格问题³¹。

3.2b 四类边界的完整定义与判据Copy Anchor Link

3.2 节列了四类语义边界,这里给每类一个「为什么是它」的判据³²:

反过来,两个反例也成立:在单条查询处 catch——你不知道该不该回滚, 因为组里还有三条没跑;在应用顶层 catch——你知道该「记日志、 返回 500」,可「具体哪一步、为什么失败」已经在四层拆除里磨没了³³。 事务例程里那个 throw new Error('Profile update failed', { cause: e }) 的写法,是「边界上抛干净的 + 链条上保完整的」的标准动作: 外层拿到一句人话,内层的原始错误躺在 cause 里跟着走³⁴。

3.3b finally 的全规则与两个反例的展开Copy Anchor Link

finally 的规则比「总是执行」多一条关键的:它能劫持传播中的错误。 原书的两个反例,展开看状态³⁵:

function suppressed() {
  try {
    throw new Error("This disappears");
  } finally {
    return "Success!";     // return 先发生:错误对象还在,但传播被打断
  }                          // 调用方收到 "Success!",毫无异常迹象
}
function replaced() {
  try {
    throw new Error("This disappears");
  } finally {
    throw new Error("This replaces it");   // 新错误顶替旧错误上塔
  }                                          // 调用方只看得见新的
}

原错误对象其实还活着——栈抓了、消息设了——但传播途中被 finally 截胡,一切白搭,恢复与调试两头的信息全部作废³⁶。 书里给这种行为的定性是:规范有意给开发者的最大控制权, 本意是让资源清理不被异常打断;可对不小心的人,它是上了膛的脚枪³⁷。 纪律因此只有一条:finally 里只做清理,绝不 return、绝不 throw。 需要「清理后还要抛」的场景,把清理放 finally、把抛留在外面:

let tx;
try {
  tx = db.beginTransaction();
  tx.query('...');
  tx.commit();
} catch (e) {
  tx.rollback();            // 恢复动作
  throw new Error('update failed', { cause: e });   // 重抛放在 catch 里
} finally {
  tx.close();               // finally 只负责关门
}

3.4b 「别拿 throw 当流程控制」的完整论证Copy Anchor Link

原书把这条禁令写成了带历史背景的论证,值得照录³⁸。反模式长这样:

function findItem(array, test) {
  try {
    array.forEach((item) => {
      if (test(item)) throw item;    // 把 throw 当 break 使
    });
  } catch (result) {
    return result;
  }
}

「找到就抛、外层接住当返回值」——把异常机制当 goto。 历史上这招是真性能的灾难:早期的 V8 优化不了 try-catch, 这种写法的性能可以直接杀死应用;如今引擎能优化了, 它仍然是烂代码:可读性、可调试性、维护性全线崩塌³⁹。 规则书里写得很死:该用 return/break/continue 的地方就用它们; throw/try/catch 只留给真正的异常⁴⁰。 一句话版本:异常是「计划外的出口」,不是「方便的跳转」。

3.5b 异步断层的完整时序图Copy Anchor Link

3.5 节用文字讲了「调用栈消失」,这里把时序摆开—— 这是本章最重要的一张图:

  主栈时间线 ──────────────────────────────────────────►
    try {                                   ← 包含 try-catch
      processData(data) ──► setTimeout(cb, 100)   ← 登记回调,不执行
    } catch (e) { ... }                     ← 跟着主栈一起结束
    [主栈销毁]                              ← 100ms 前就已不存在

  100ms 后,事件循环启动一个全新的栈:
    cb() ──► throw new Error(...)          ← 栈上只有定时器内部帧
    ↑ 这个栈与当初调 processData 的栈没有任何连接
    ↑ try-catch 是上一个栈的遗物,物理上够不着

错的不只是「catch 够不着」:栈里也只剩新栈的三行—— Timeout._onTimeout、listOnTimeout、processTimers, 没有任何一行告诉你「这是 processData 排的队、排它是为了处理什么数据」⁴¹。 恢复侧与调试侧在这张图上是同一场塌方:错误的「来源上下文」 (谁排的、为什么排)随旧栈一起死了,剩下的只有一个裸错误 掉在全新的世界里——它能落进的地方只有全局处理器。

3.6b 全局处理器的能力边界:一张对照表Copy Anchor Link

两个用途都是真的:记日志、报监控。但两个局限同样硬—— 对恢复:全局处理器离现场太远,错误到这时,不知道当时在做什么操作、 涉及什么数据、系统处于什么状态,能做的只有记录加祈祷⁴³; 对调试:同步错误的栈虽完整,可已经穿过不知多少层抽象; 异步错误的栈照旧残缺。书里那句定性值得背: 「全局处理器是错误被记录的地方,不是错误被理解的地方。」⁴⁴

所以最终定调只有一句:真正的解法是在语义边界上接住错误, 别让它们走到这一步;全局处理器是安全网,用来兜「错误处理本身的失误」。 错误经常落到全局处理器,信号很明确——边界的错误处理缺位了⁴⁵。

3.7 本章的章末总结(原书十条)Copy Anchor Link

原书第 7 章结尾给了十条总结,照录作核对单⁴⁶:

1. 可以 throw 任何值,但带栈的 Error 对象是恢复与调试两用的约定俗成;
2. 原生类型(TypeError/RangeError)描述语言违规,不给恢复指导; AggregateError 与 DOMException 的语义类型更实用;
3. cause 支持边界处包错误:对外干净、对内保完整链;
4. Node.js 错误码把机器恢复与人读消息分开,告别了脆弱的「匹配消息」;
5. 调用栈为调试抓现场,代价是实打实的内存与 CPU;惰性序列化与限深度是对策;
6. try-catch 的传播是逐帧拆除,直到找到处理器或撞毁;
7. catch 放语义边界:事务、API、用户操作、资源;
8. finally 保证清理,但 return/throw 会吞错换错;
9. setTimeout 等异步操作拆掉调用栈,try-catch 失效,栈丢失调度上下文;
10. 全局处理器是兜底网;错误常落到那里 = 边界处理缺位。

十条里有六条是「不要做什么」——错误处理这个主题,禁令比技法多。 这倒符合它的本质:错误路径是平时走不到、出事时救命的路, 它的每一处分岔都要在出事前就定好。 而定分岔的依据,就是 「恢复要上下文、调试要现场、两者成本对立」这条主线。

3.7b 与第 1 章的闭环:队列里的错误没人接Copy Anchor Link

把第 1 章的队列图和本章的旅程图叠在一起,一个完整的画面就出来了: 错误在同一次调用栈里 throw 时,try-catch 是有效的——它们共享同一摞帧; 错误在另一个任务里 throw 时,两个任务的栈中间隔着整个事件循环, try-catch 物理上够不着⁴⁷。所以「异步边界断裂」不是错误系统的缺陷, 而是调度系统的必然:01 章学的每一个队列(microtask、nextTick、 immediates、定时器),都是一道栈的断层线;错误每跨过一条, 就要么靠 Promise 链那套「平行的栈」接力,要么掉进全局处理器⁴⁸。

这条闭环也解释了第 1 章那个反常的断言——「微任务队列和事件循环 没有直接关系」⁴⁹:微任务是语言定义的队列,宿主想什么时候清就什么时候清; 而错误传播恰恰依赖「同一摞帧」,宿主对队列的自由裁量, 等于对错误传播路径的自由裁量。调度的自由,就是错误处理的代价—— 同一个硬币的两面,被这本书拆在两章里讲完。

作者的判断与证据Copy Anchor Link

有证据的判断:

• try-catch/finally/setTimeout 的行为演示都是可运行的代码, 「Never executed」「Never catches it」这些输出都可直接复现⁵⁰;
• 「Node 视未捕获为致命」是 Node 文档明载的行为⁵¹。

作者的主张:

• 「catch 放语义边界」是本 书的核心实践主张之一; 「四类边界」清单是作者经验归纳,不是规范分类。
• 「全局处理器只配当安全网」是立场鲜明的定调; 现实中(尤其在短生命周期脚本、CLI 工具里)把 uncaughtException 当主策略用的代码不少,书里没讨论这些场景的宽容度。

边界与局限Copy Anchor Link

• Promise/async 的错误传播(本书多次预告的「第 8 章」)在 MEAP 里 不存在——异步错误机制的正确答案这一章故意只开了个头; async/await 如何用 try-catch 找回同步感,要等最终版。
• async stack traces 的具体能力(V8 的 --async-stack-traces 及默认行为) 书中只给了一段落,细节随版本变化。
• 浏览器 unhandledrejection 事件(Promise 专属兜底)全书未提—— 它是和 uncaughtException 平行的另一半兜底体系。
• Worker/跨线程的错误传播(postMessage 传不了 Error 等)不在范围。

可带走的Copy Anchor Link

1. throw 劫持控制流、沿栈逐帧拆除;catch 在哪,拆除就停在哪。
2. catch 放深了下不了恢复决策,放高了丢调试细节——放语义边界上。
3. 四类边界:事务、API、用户操作、资源;事务示例的模式(rollback + cause 重抛)直接可抄。
4. finally 永远执行,但 return/throw 会吞掉或替换原错误;finally 只清理。
5. throw 不是流程控制;return/break/continue 干它们该干的事。
6. setTimeout 等异步回调里抛错,外层 try-catch 永远接不住——栈已经没了。
7. async stack traces 补调试不补恢复,且对 Web API 调度完全无效。
8. 全局处理器(浏览器 error 事件 / Node uncaughtException)只配当安全网; 错误常落到这里 = 边界错误处理缺位。
9. finally 里只清理,绝不 return、绝不 throw;要重抛放在 catch 里。
10. 异步回调里抛错先想「栈还在吗」;不在,就让错误走 Promise 链或别抛。

原文地图Copy Anchor Link