JavaScript错误处理如何优雅捕获异常【教程】

javaScript异常捕获难点在于异步错误处理：try/catch仅捕获同步错误；promise拒绝需用.catch()或async/await中try包裹await；全局未处理拒绝用unhandledrejection事件兜底；错误应自定义分类并结合业务语义决策重试、降级或中断。

javascript 中的异常捕获本身不难，难的是在真实项目里不漏掉异步错误、不吞掉有用堆栈、不误判 Promise 拒绝为“已处理”。try/catch 只对同步代码有效，而现代 js 大量依赖 Promise、async/await 和事件回调，这些地方才是异常丢失的重灾区。

为什么 try/catch 抓不到 Promise 拒绝？

因为 Promise 的拒绝（reject）默认不是“抛出异常”，而是触发一个未处理的 rejection，浏览器或 node.js 会等微任务队列清空后才报错——此时 try/catch 早已退出作用域。

常见错误写法：

try {   Promise.reject(new Error('boom')); } catch (e) {   console.log('不会执行'); }

正确做法是显式处理 Promise 链：

立即学习“Java免费学习笔记（深入）”；

• 用 .catch() 接住链尾拒绝
• 在 async/await 函数中用 try/catch 包裹 await 表达式（注意：只对当前 await 有效）
• 避免在 then() 回调里抛错却不接 catch()，否则变成 unhandledrejection

如何全局捕获未处理的 Promise 拒绝？

靠 window.addEventListener('unhandledrejection')（浏览器）或 process.on('unhandledRejection')（node.js），但仅作兜底，不能替代主动处理。

关键点：

• 该事件只触发一次，且无法阻止默认行为（如控制台报错）
• 事件对象有 reason（错误对象）和 promise（被拒绝的 Promise 实例）
• 不要在这里 throw 或 reject，否则可能引发二次事件
• 适合做日志上报，不适合做业务恢复

示例（浏览器端）：

window.addEventListener('unhandledrejection', event => {   console.error('Unhandled rejection:', event.reason);   // 上报监控系统   reportError(event.reason);   // ⚠️ 不要写 event.preventDefault() —— 它无效 });

异步操作嵌套时，catch 该放在哪一层？

原则：谁启动异步，谁负责兜底；谁消费结果，谁决定错误走向。不要把所有 catch 堆在最外层。

典型陷阱：

• 在 fetch 后直接 .json() 却没处理 json() 自身可能抛出的语法错误
• 多个 await 连续调用，只在外层 try，导致中间某步失败后后续逻辑仍执行
• 使用 Promise.all() 时，一个失败就全盘 reject，但你其实只想忽略个别失败 —— 改用 Promise.allSettled()

推荐结构：

async function loadData() {   try {     const res = await fetch('/api/data');     if (!res.ok) throw new Error(`HTTP ${res.status}`);          try {       const data = await res.json(); // 可能 SyntaxError       return data;     } catch (e) {       throw new Error('Invalid JSON response');     }   } catch (e) {     // 统一处理网络、解析、业务逻辑错误     logError(e);     throw e; // 保持可追溯性，不静默吞掉   } }

错误对象本身该怎么构造和区分？

原生 Error 对象只有 message 和 stack，但真实场景需要类型、状态码、上下文数据。别只靠 instanceof 判断。

实操建议：

• 自定义错误类继承 Error，添加 name、code、status 等字段
• 避免用字符串匹配判断错误原因（如 e.message.includes('timeout')），改用 e.code === 'NETWORK_TIMEOUT'
• 在日志中保留原始 cause（ES2022+ 支持 new Error(msg, { cause })）
• 第三方库（如 Axios）的错误对象结构特殊，务必查文档，例如 error.response?.data 才是后端返回体

示例：

class ApiError extends Error {   constructor(message, { code, status, details } = {}) {     super(message);     this.name = 'ApiError';     this.code = code;     this.status = status;     this.details = details;   } }

真正难的不是写 catch，而是判断哪个错误该重试、哪个该降级、哪个该直接中断用户流程——这需要结合业务语义，而不是靠一套通用错误处理函数自动解决。