try-catch仅捕获同步错误,异步错误需结合async/await+try-catch、unhandledrejection监听等;finally用于资源清理;应抛Error实例而非字符串,便于调试与监控。

try-catch 捕获同步错误最常用,但别漏掉 finally
JavaScript 中 try-catch 是处理同步异常的标配,但它只捕获当前执行栈中抛出的错误,对异步操作(如 setTimeout、Promise 回调)无效。常见误用是以为加了 try-catch 就能兜住所有错误,结果发现 fetch 失败或 JSON.parse 报错仍导致白屏或未处理的 Uncaught SyntaxError。
实操建议:
-
catch块里务必检查error类型,避免把null或非Error实例当异常处理 - 需要清理资源(如关闭定时器、释放锁)时,把逻辑放在
finally里,它无论是否出错都会执行 - 不要空
catch:至少记录console.error(error)或上报到监控系统
try {
const data = JSON.parse(invalidJson);
render(data);
} catch (err) {
if (err instanceof SyntaxError) {
console.error('JSON 解析失败:', err.message);
showErrorMessage('数据格式异常');
} else {
throw err; // 不认识的错误,继续上抛
}
} finally {
hideLoading();
}
async/await 必须配合 try-catch,Promise.catch 不能跨 await 链自动传递
写 async 函数时,很多人习惯在最后链一个 .catch(),但这样会漏掉 await 后面语句抛出的错误——因为 await 已将 Promise 转为同步流程,错误不再走 Promise 链。
常见错误现象:await fetch('/api') 成功,但后续 await res.json() 报错,却没被外层 .catch() 捕获。
立即学习“Java免费学习笔记(深入)”;
实操建议:
- 每个
await行都应处于try块内,或确保前一个await的 Promise 已用.catch()处理并返回“安全值” - 避免混合写法:不要在
async函数里既用try-catch又在外层调用处再链.catch(),容易重复处理或遗漏 - 注意
Promise.all:任一子 Promise 拒绝会导致整个失败,需提前用.catch(() => null)包装单个 Promise 来隔离错误
async function loadData() {
try {
const res = await fetch('/api');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json(); // 这行可能 SyntaxError,必须在 try 内
return data;
} catch (err) {
console.error('加载失败:', err);
return null;
}
}
window.onerror 和 window.addEventListener('error') 用于捕获全局 JS 错误
这些机制能抓到未被 try-catch 捕获的运行时错误,包括脚本加载失败、语法错误、跨域脚本错误(但此时 error 对象信息受限,message 和 stack 为空)。
关键限制:它们不捕获 Promise 拒绝(unhandledrejection 是独立事件),也不捕获 console.error 手动打的日志。
实操建议:
- 必须在所有脚本执行前注册,否则早期错误会丢失
- 生产环境建议搭配
addEventListener('unhandledrejection', ...)一起使用,覆盖 Promise 场景 - 注意跨域脚本:CDN 上的 JS 报错时,浏览器出于安全限制只给
Script error.,需在标签加crossorigin属性并确保服务端返回Access-Control-Allow-Origin
window.addEventListener('error', (event) => {
console.log('全局错误:', {
message: event.message,
filename: event.filename,
lineno: event.lineno,
colno: event.colno,
});
});
window.addEventListener('unhandledrejection', (event) => {
console.log('未处理 Promise 拒绝:', event.reason);
});
throw new Error() 比 throw 'string' 更利于调试和分类
直接 throw '网络超时' 看似简单,但会让错误失去堆栈、类型和标准化属性,后续无法用 instanceof Error 判断,监控系统也难做聚合分析。
实际项目中,自定义错误类或带 code 的 Error 实例能显著提升问题定位效率,比如区分业务错误(AuthError)、网络错误(NetworkError)、校验错误(ValidationError)。
实操建议:
- 所有手动抛错统一用
new Error(msg),哪怕只是临时调试 - 添加额外字段:如
err.code = 'NETWORK_TIMEOUT'、err.meta = { url, method },便于日志筛选 - 避免在
catch中吞掉原错误又不保留err.stack,这会让排查断层
class ValidationError extends Error {
constructor(message, field) {
super(message);
this.name = 'ValidationError';
this.field = field;
}
}
// 使用
if (!email.includes('@')) {
throw new ValidationError('邮箱格式不正确', 'email');
}
错误处理真正难的不是语法,而是决定在哪一层抛、在哪一层收、哪些该静默、哪些必须阻断用户操作。尤其在微前端或 SDK 场景下,错误边界(componentDidCatch / errorBoundary)和跨沙箱错误透传,很容易被忽略。











