大多数工程师可能并没留意过 JS 中错误对象、错误堆栈的细节,即使他们每天的日常工作会面临不少的报错,部分同学甚至在 console 的错误面前一脸懵逼,不知道从何开始排查,如果你对本文讲解的内容有系统的了解,就会从容很多。而错误堆栈清理能让你有效去掉噪音信息,聚焦在真正重要的地方,此外,如果理解了 Error 的各种属性到底是什么,你就能更好的利用他。
接下来,我们就直奔主题。
在探讨 JS 中的错误之前,我们必须理解调用栈(Call Stack)的工作机制,其实这个机制非常简单,如果你对这个已经一清二楚了,可以直接跳过这部分内容。
简单的说:函数被调用时,就会被加入到调用栈顶部,执行结束之后,就会从调用栈顶部移除该函数,这种数据结构的关键在于后进先出,即大家所熟知的 LIFO。比如,当我们在函数 y 内部调用函数 x 的时候,调用栈从下往上的顺序就是 y -> x 。
我们再举个代码实例:
function c() {
console.log('c');
}
function b() {
console.log('b');
c();
}
function a() {
console.log('a');
b();
}
a();
这段代码运行时,首先 a 会被加入到调用栈的顶部,然后,因为 a 内部调用了 b,紧接着 b 被加入到调用栈的顶部,当 b 内部调用 c 的时候也是类似的。在调用 c的时候,我们的调用栈从下往上会是这样的顺序:a -> b -> c。在 c 执行完毕之后,c 被从调用栈中移除,控制流回到 b 上,调用栈会变成:a -> b,然后 b 执行完之后,调用栈会变成:a,当 a 执行完,也会被从调用栈移除。
为了更好的说明调用栈的工作机制,我们对上面的代码稍作改动,使用 console.trace 来把当前的调用栈输出到 console 中,你可以认为console.trace 打印出来的调用栈的每一行出现的原因是它下面的那行调用而引起的。
function c() {
console.log('c');
console.trace();
}
function b() {
console.log('b');
c();
}
function a() {
console.log('a');
b();
}
a();
当我们在 Node.js 的 REPL 中运行这段代码,会得到如下的结果:
Trace
at c (repl:3:9)
at b (repl:3:1)
at a (repl:3:1)
at repl:1:1 // <-- 从这行往下的内容可以忽略,因为这些都是 Node 内部的东西
at realRunInThisContextScript (vm.js:22:35)
at sigintHandlersWrap (vm.js:98:12)
at ContextifyScript.Script.runInThisContext (vm.js:24:12)
at REPLServer.defaultEval (repl.js:313:29)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
显而易见,当我们在 c 内部调用 console.trace 的时候,调用栈从下往上的结构是:a -> b -> c。如果把代码再稍作改动,在 b 中 c 执行完之后调用,如下:
function c() {
console.log('c');
}
function b() {
console.log('b');
c();
console.trace();
}
function a() {
console.log('a');
b();
}
a();
通过输出结果可以看到,此时打印的调用栈从下往上是:a -> b,已经没有 c 了,因为 c 执行完之后就从调用栈移除了。
Trace
at b (repl:4:9)
at a (repl:3:1)
at repl:1:1 // <-- 从这行往下的内容可以忽略,因为这些都是 Node 内部的东西
at realRunInThisContextScript (vm.js:22:35)
at sigintHandlersWrap (vm.js:98:12)
at ContextifyScript.Script.runInThisContext (vm.js:24:12)
at REPLServer.defaultEval (repl.js:313:29)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
at REPLServer.onLine (repl.js:513:10)
再总结下调用栈的工作机制:调用函数的时候,会被推到调用栈的顶部,而执行完毕之后,就会从调用栈移除。
当代码中发生错误时,我们通常会抛出一个 Error 对象。Error 对象可以作为扩展和创建自定义错误类型的原型。Error 对象的 prototype 具有以下属性:
上面都是标准属性,有些 JS 运行环境还提供了标准属性之外的属性,如 Node.js、Firefox、Chrome、Edge、IE 10、Opera 和 Safari 6+ 中会有 stack 属性,它包含了错误代码的调用栈,接下来我们简称错误堆栈。错误堆栈包含了产生该错误时完整的调用栈信息。如果您想了解更多关于 Error 对象的非标准属性,我强烈建议你阅读 MDN 的这篇文章。
抛出错误时,你必须使用 throw 关键字。为了捕获抛出的错误,则必须使用 try catch 语句把可能出错的代码块包起来,catch 的时候可以接收一个参数,该参数就是被抛出的错误。与 Java 中类似,JS 中也可以在 try catch 语句之后有 finally,不论前面代码是否抛出错误 finally 里面的代码都会执行,这种语言的常见用途有:在 finally 中做些清理的工作。
此外,你可以使用没有 catch 的 try 语句,但是后面必须跟上 finally,这意味着我们可以使用三种不同形式的 try 语句:
try 语句还可以嵌套在 try 语句中,比如:
try {
try {
throw new Error('Nested error.'); // 这里的错误会被自己紧接着的 catch 捕获
} catch (nestedErr) {
console.log('Nested catch'); // 这里会运行
}
} catch (err) {
console.log('This will not run.'); // 这里不会运行
}
try 语句也可以嵌套在 catch 和 finally 语句中,比如下面的两个例子:
try {
throw new Error('First error');
} catch (err) {
console.log('First catch running');
try {
throw new Error('Second error');
} catch (nestedErr) {
console.log('Second catch running.');
}
}
try {
console.log('The try block is running...');
} finally {
try {
throw new Error('Error inside finally.');
} catch (err) {
console.log('Caught an error inside the finally block.');
}
}
同样需要注意的是,你可以抛出不是 Error 对象的任意值。这可能看起来很酷,但在工程上却是强烈不建议的做法。如果恰巧你需要处理错误的调用栈信息和其他有意义的元数据,抛出非 Error 对象的错误会让你的处境很尴尬。
假如我们有如下的代码:
function runWithoutThrowing(func) {
try {
func();
} catch (e) {
console.log('There was an error, but I will not throw it.');
console.log('The error\'s message was: ' + e.message)
}
}
function funcThatThrowsError() {
throw new TypeError('I am a TypeError.');
}
runWithoutThrowing(funcThatThrowsError);
如果 runWithoutThrowing 的调用者传入的函数都能抛出 Error 对象,这段代码不会有任何问题,如果他们抛出了字符串那就有问题了,比如:
function runWithoutThrowing(func) {
try {
func();
} catch (e) {
console.log('There was an error, but I will not throw it.');
console.log('The error\'s message was: ' + e.message)
}
}
function funcThatThrowsString() {
throw 'I am a String.';
}
runWithoutThrowing(funcThatThrowsString);
这段代码运行时,runWithoutThrowing 中的第 2 次 console.log 会抛出错误,因为 e.message 是未定义的。这些看起来似乎没什么大不了的,但如果你的代码需要使用 Error 对象的某些特定属性,那么你就需要做很多额外的工作来确保一切正常。如果你抛出的值不是 Error 对象,你就不会拿到错误相关的重要信息,比如 stack,虽然这个属性在部分 JS 运行环境中才会有。
Error 对象也可以向其他对象那样使用,你可以不用抛出错误,而只是把错误传递出去,Node.js 中的错误优先回调就是这种做法的典型范例,比如 Node.js 中的 fs.readdir 函数:
const fs = require('fs');
fs.readdir('/example/i-do-not-exist', function callback(err, dirs) {
if (err) {
// `readdir` will throw an error because that directory does not exist
// We will now be able to use the error object passed by it in our callback function
console.log('Error Message: ' + err.message);
console.log('See? We can use Errors without using try statements.');
} else {
console.log(dirs);
}
});
此外,Error 对象还可以用于 Promise.reject 的时候,这样可以更容易的处理 Promise 失败,比如下面的例子:
new Promise(function(resolve, reject) {
reject(new Error('The promise was rejected.'));
}).then(function() {
console.log('I am an error.');
}).catch(function(err) {
if (err instanceof Error) {
console.log('The promise was rejected with an error.');
console.log('Error Message: ' + err.message);
}
});
Node.js 才支持这个特性,通过 Error.captureStackTrace 来实现,Error.captureStackTrace 接收一个 object 作为第 1 个参数,以及可选的 function 作为第 2 个参数。其作用是捕获当前的调用栈并对其进行裁剪,捕获到的调用栈会记录在第 1 个参数的 stack 属性上,裁剪的参照点是第 2 个参数,也就是说,此函数之前的调用会被记录到调用栈上面,而之后的不会。
让我们用代码来说明,首先,把当前的调用栈捕获并放到 myObj 上:
const myObj = {};
function c() {
}
function b() {
// 把当前调用栈写到 myObj 上
Error.captureStackTrace(myObj);
c();
}
function a() {
b();
}
// 调用函数 a
a();
// 打印 myObj.stack
console.log(myObj.stack);
// 输出会是这样
// at b (repl:3:7) <-- Since it was called inside B, the B call is the last entry in the stack
// at a (repl:2:1)
// at repl:1:1 <-- Node internals below this line
// at realRunInThisContextScript (vm.js:22:35)
// at sigintHandlersWrap (vm.js:98:12)
// at ContextifyScript.Script.runInThisContext (vm.js:24:12)
// at REPLServer.defaultEval (repl.js:313:29)
// at bound (domain.js:280:14)
// at REPLServer.runBound [as eval] (domain.js:293:12)
// at REPLServer.onLine (repl.js:513:10)
上面的调用栈中只有 a -> b,因为我们在 b 调用 c 之前就捕获了调用栈。现在对上面的代码稍作修改,然后看看会发生什么:
const myObj = {};
function d() {
// 我们把当前调用栈存储到 myObj 上,但是会去掉 b 和 b 之后的部分
Error.captureStackTrace(myObj, b);
}
function c() {
d();
}
function b() {
c();
}
function a() {
b();
}
// 执行代码
a();
// 打印 myObj.stack
console.log(myObj.stack);
// 输出如下
// at a (repl:2:1) <-- As you can see here we only get frames before `b` was called
// at repl:1:1 <-- Node internals below this line
// at realRunInThisContextScript (vm.js:22:35)
// at sigintHandlersWrap (vm.js:98:12)
// at ContextifyScript.Script.runInThisContext (vm.js:24:12)
// at REPLServer.defaultEval (repl.js:313:29)
// at bound (domain.js:280:14)
// at REPLServer.runBound [as eval] (domain.js:293:12)
// at REPLServer.onLine (repl.js:513:10)
// at emitOne (events.js:101:20)
在这段代码里面,因为我们在调用 Error.captureStackTrace 的时候传入了 b,这样 b 之后的调用栈都会被隐藏。
现在你可能会问,知道这些到底有啥用?如果你想对用户隐藏跟他业务无关的错误堆栈(比如某个库的内部实现)就可以试用这个技巧。
vue工程npm run serve/start/dev启动时,node_modules文件报:Cannot read property range of null 错误,该问题是babel-eslint版本更新问题导致的;
在ajax请求后台数据时有时会报 HTTP 400 错误 - 请求无效 (Bad request);出现这个请求无效报错说明请求没有进入到后台服务里;原因:前端提交数据的字段名称或者是字段类型和后台的实体类不一致
我们都知道 try catch 无法捕获 setTimeout 异步任务中的错误,那其中的原因是什么。以及异步代码在 js 中是特别常见的,我们该怎么做才比较?
父页面初始化声明变量a为数组(数组对象是引用类型,赋值传递的是地址),创建iframe子页面后给父页面变量a赋值,赋值后销毁iframe子页面,再次调用变量a的时候就会抛出异常‘SCRIPT5011:不能执行已释放Script的代码’。
js错误的实质,也是发出一个事件,处理他,error实例对象message:错误提示信息,name:错误名称(非标准属性)宿主环境赋予
文件上传的功能时候,调用fs.renameSync方法错误,这个提示是跨区重命名文件出现的权限问题。先从源文件拷贝到另外分区的目标文件,然后再unlink,就可以了。
如果在JavaScript中使用innerHTML,缺点是:内容随处可见;不能像“追加到innerHTML”一样使用;innerHTML不提供验证,因此我们可能会在文档中插入有效的和破坏性的HTML并将其中断
现在,有越来越多所谓的“教程”来帮助我们提高网站的易用性。我们收集了一些在Web开发中容易出错和被忽略的小问题,并且提供了参考的解决方案,以便于帮助Web开发者更好的完善网站。
为什么要做前端错误监控?1. 为了保证产品的质量2. 有些问题只存在于线上特定的环境3. 后端错误有监控,前端错误没有监控,前端错误分为两类: 即时运行错误和资源加载错误
当我们在进行开发的时候,通常需要属于我们自己的错误类来反映任务中可能出现的特殊情况。对于网络操作错误,我们需要 HttpError,对于数据库操作错误,我们需要 DbError,对于搜索操作错误,我们需要 NotFoundError,等等
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!