前言:这几天把公司的项目清理了一下,对一些细节进行了优化,然后翻到了之前做的时候留下了一点笔记,顺手整理一下就诞生了这篇总结~
异常捕获
try-catch
try {
error // 未定义变量
} catch(e) {
console.log('我知道错误了');
console.log(e);
}
try-catch 处理异常的能力有限,只能捕获捉到运行时非异步错误,对于语法错误和异步错误就显得无能为力,捕捉不到。
window.onerror
window.onerror = function (msg, url, row, col, error) {
console.log('我知道异步错误了');
console.log({
msg, url, row, col, error
})
return true;
};
setTimeout(() => {
error;
});
window.onerror 捕获异常能力比 try-catch 稍微强点,无论是异步还是非异步错误,onerror 都能捕获到运行时错误。
然而 window.onerror 对于语法错误还是无能为力,所以我们在写代码的时候要尽可能避免语法错误的,不过一般这样的错误会使得整个页面崩溃,还是比较容易能够察觉到的。
onerror 与 try-catch 区别
在实际的使用过程中,onerror 主要是来捕获预料之外的错误,而 try-catch 则是用来在可预见情况下监控特定的错误,两者结合使用更加高效。
window.onerror 细节
-
onerror 函数只有在返回 true 的时候,异常才不会向上抛出,否则即使是知道异常的发生控制台还是会显示 Uncaught Error: xxxxx。
-
对于 onerror 这种全局捕获,最好写在所有 JS 脚本的前面,因为你无法保证你写的代码是否出错,如果写在后面,一旦发生错误的话是不会被 onerror 捕获到的。
-
onerror 是无法捕获到网络异常的错误(静态资源加载可以用 DOM2级事件监听)
<script> window.onerror = function (msg, url, row, col, error) { console.log('我知道异步错误了'); console.log({ msg, url, row, col, error }) return true; }; </script> <img src="./404.png">
addEventListener(‘error’)
通过addEventListener(‘error’)监控静态资源加载,由于网络请求异常不会事件冒泡,因此必须在捕获阶段将其捕捉到才行,而且无法判断错误状态码,所以还需要配合服务端日志才能进行排查分析。
缺点:仍然无法捕获异常时网络请求的状态码
<script>
window.addEventListener('error', (msg, url, row, col, error) => {
console.log('我知道 404 错误了');
console.log(
msg, url, row, col, error
);
return true;
}, true);
</script>
<img