JavaScript错误处理与try-catch使用教程

JavaScript错误处理远不止简单套用try-catch，它是一套需分场景精准施策的体系：try-catch仅对同步异常立竿见影，而Promise、async/await、事件回调等异步错误必须借助.catch()、await配合或回调内嵌等方式捕获；finally虽保证清理逻辑必执行，却绝不掩盖错误本质；全局监听（如onerror、unhandledrejection）只是不可靠错误的“急救上报通道”，绝非恢复手段——真正考验开发者的是根据业务语义判断“该不该捕、在哪捕、捕后如何响应”，比如用户输入解析失败需明确提示，而非关键埋点失败则宜静默忽略，让错误处理从语法技巧升维为工程决策。

JavaScript 错误处理不是只有 try-catch 一种方式，但它是同步代码中捕获和响应异常最直接、最可控的手段。异步场景下它默认不生效，必须配合其他机制补全。

什么时候 try-catch 能捕获到错误

try-catch 只能捕获同步执行过程中抛出的异常（throw 或运行时错误），比如 JSON.parse 解析失败、访问 undefined 的属性、调用不存在的方法等。

常见误区是以为它能捕获 setTimeout、Promise、事件回调里的错误——其实不能，除非你在回调内部自己写 try-catch。

• ✅ 能捕获：JSON.parse("{")、undefined.foo()、throw new Error("boom")
• ❌ 不能直接捕获：Promise.reject()、fetch().catch()、setTimeout(() => { throw "oops" })
• ⚠️ 注意：async 函数里 await 后的 Promise rejection 会被转为同步异常，此时 try-catch 有效

try-catch-finally 各部分的实际作用

finally 块无论是否发生异常都会执行，适合做清理工作（如关闭加载状态、释放资源），但它不会“吞掉”错误——如果 catch 中没 return 或 rethrow，错误仍会向上冒泡。

示例：

try {
  riskyOperation();
} catch (err) {
  console.error("处理失败", err.message);
  // 没有 rethrow，错误到这里就结束了
} finally {
  setLoading(false); // 总会执行
}

• catch 参数名不是固定 err，可以是任意合法标识符，如 e、error
• catch 块内若再次 throw，错误继续向外传播；若只 console.error 不处理，等于静默丢弃
• finally 中 return 会覆盖 try 或 catch 中的返回值（慎用）

Promise 和 async/await 中的错误捕获要点

Promise 链中错误需用 .catch() 或 await 配合 try-catch，两者语义不同：前者是异步错误处理管道，后者是语法糖包装后的同步风格异常流。

• ❌ 错误写法：try { Promise.reject("fail") } catch(e) { ... } —— 这里 Promise.reject 不抛同步异常
• ✅ 正确写法1：Promise.reject("fail").catch(console.error)
• ✅ 正确写法2：async () => { try { await Promise.reject("fail") } catch(e) { ... } }
• ⚠️ 注意：await 后面如果不是 Promise，try-catch 仍按同步逻辑工作（比如 await JSON.parse("{") 会进 catch）

全局错误监听作为兜底方案

未被任何 try-catch 或 .catch() 捕获的错误，会触发全局事件。浏览器中可用 window.onerror 或 window.addEventListener("error")；Node.js 中用 process.on("uncaughtException")。

但它们只是监控和上报手段，不适合用来“恢复”程序状态——因为错误发生时执行栈已不可控，强行续跑容易引发更隐蔽的问题。

• window.onerror 能捕获脚本错误、资源加载失败（如 JS 文件 404），但捕获不到 Promise rejection（需额外监听 unhandledrejection）
• unhandledrejection 事件可用于拦截未被 .catch() 处理的 Promise 错误，常用于日志记录
• 这些监听器不能替代局部错误处理，只是最后一道防线

真正难的不是写 try-catch，而是判断该不该捕、在哪捕、捕了之后怎么响应——比如解析用户输入的 JSON，失败要提示；但某个非关键埋点上报失败，通常该静默忽略。边界模糊的地方，往往得结合业务语义来定。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。