Javascript学习之调用栈的工作机制详解

本文通过剖析 JS  中调用栈的工作机制，讲解错误抛出、处理的正确姿势，以及错误堆栈的获取、清理处理方法，希望大家对这个少有人关注但极其有用的知识点能够有所理解和掌握，同时对大家 学习javascript有所帮助 。

　　大多数工程师可能并没留意过 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  对象可以作为扩展和创建自定义错误类型的原型。 Error  对象的  prototype  具有以下属性：

　　· constructor -  负责该实例的原型构造函数；

　　· message -  错误信息；

　　· name -  错误的名字；

　　上面都是标准属性，有些 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 ... catch

　　· try ... finally

　　· try ... catch ... finally

　　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.stackconsole.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.stackconsole.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  之后的调用栈都会被隐藏。

　　现在你可能会问，知道这些到底有啥用？如果你想对用户隐藏跟他业务无关的错误堆栈（比如某个库的内部实现）就可以试用这个技巧。

　　 总结

　　通过本文的描述，相信你对 JS  中的调用栈、 Error  对象、错误堆栈有了清晰的认识，在遇到错误的时候不在慌乱。如果对文中的内容有任何疑问，欢迎在下面评论。

来源： 前端周刊