A brief analysis of JavaScript error handling and stack tracing

Sometimes in the process of our code accumulation, some details of error handling and stack traces are ignored, but if you pay attention to these details, they are very useful for writing libraries related to testing or error handling. Now I will give you a great processing idea. This idea can greatly improve the way we handle the stack. When the user's assertion fails, we will give more prompt information (to help the user locate).

Properly handling stack information allows you to clear useless data and focus only on useful data. At the same time, a better understanding of the Errors object and its related properties can help you make fuller use

Errors.

How the call stack (function) works

Before talking about errors, we must first understand the principle of the call stack (function):

When a function is called, it is pushed to the top of the stack. After the function is completed, it will be removed from the top of the stack.

The data structure of the stack is backward First out, known as LIFO (last in, first out).

For example:

function c() {
    console.log('c');
}
function b() {
    console.log('b');
    c();
}
function a() {
    console.log('a');
    b();
}
a();

In the above example, when function a runs , which will be added to the top of the stack. Then, when function b is called inside function a, function b will be pushed to the top of the stack. When function c is called inside function b It will also be pushed to the top of the stack when called.

When function c runs, the stack contains a, b and c (in this order).

When function c runs After completion, it will be removed from the top of the stack, and then the control flow of the function call returns to function b. After function b finishes running, it will also be removed from the top of the stack, and then the function call

The control flow returns to function a. Finally, function a will be removed from the top of the stack after it is completed.

In order to better demonstrate the behavior of the stack in the demo, you can use console.trace( ) Output the current stack data on the console. At the same time, you have to read the output stack data in order from top to bottom.

function c() {
    console.log('c');
    console.trace();
}
function b() {
    console.log('b');
    c();
}
function a() {
    console.log('a');
    b();
}
a();

Running the above code in Node's REPL mode will get the following output:

Trace
    at c (repl:3:9)
    at b (repl:3:1)
    at a (repl:3:1)
    at repl:1:1 // <-- For now feel free to ignore anything below this point, these are Node&#39;s internals
    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)

As you can see, when output from function c, the stack contains functions a, b and c.

If running in function c After completion, output the current stack data in function b, and you will see that function c has been removed from the top of the stack. At this time, the stack only includes functions a and b.

function c() {
    console.log('c');
}
function b() {
    console.log('b');
    c();
    console.trace();
}
function a() {
    console.log('a');
    b();
}

As you can see , after function c is completed, it has been removed from the top of the stack.

Trace
    at b (repl:4:9)
    at a (repl:3:1)
    at repl:1:1  // <-- For now feel free to ignore anything below this point, these are Node&#39;s internals
    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 object and error handling

When an error occurs during program execution, an Error object is usually thrown. The Error object can be used as the prototype inherited by the user-defined error object.

Error.prototype object contains the following properties:

constructor – the constructor pointing to the instance

message – the error message

name–Error name (type)

The above are the standard properties of Error.prototype. In addition, different operating environments have their specific properties. For example, Node, Firefox, Chrome, In environments like Edge, IE 10+, Opera and Safari 6+

, the Error object has a stack attribute, which contains the stack trace of the error. The stack trace of an error instance includes the stack trace since the constructor. All stack structures.

If you want to know more about the specific properties of the Error object, you can read this article on MDN.

In order to throw an error, the throw keyword must be used. To catch a thrown error, try...catch must be used to contain the code that may cause the error. The parameter of Catch is the error instance that was thrown.

Like Java, JavaScript also allows try/catch Then use the finally keyword. After handling the error, you can do some cleanup work in the finally statement block.

In terms of syntax, you can use the try statement block without following it with the catch statement block, but it must be followed by finally block. This means there are three different try statement forms:

try...catch

try...finally

try...catch...finally

You can also embed the try statement in the Try statement:

try {
    try {
        throw new Error('Nested error.'); // The error thrown here will be caught by its own `catch` clause
    } catch (nestedErr) {
        console.log('Nested catch'); // This runs
    }
} catch (err) {
    console.log('This will not run.');
}

It can also be in catch or finally Embed try statement:

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.');
    }
}

It is important to note that when throwing an error, you can just throw a simple value instead of the Error object. Although this looks cool and is allowed, it is not A recommended approach, especially for developers of libraries and frameworks that need to deal with other people's code, because there is no standard to refer to and no way of knowing what to expect from users. You cannot trust users to throw Error objects because they May not do this, but simply throw a string or value. This also means that it is difficult to deal with stack information and other meta-information.

For example:

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);

If the user The parameter passed to the function runWithoutThrowing throws an error object, and the above code can catch the error normally. Then, if it throws a string, you will encounter some problems:

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);

现在第二个 console.log 会输出undefined. 这看起来不是很重要, 但如果你需要确保 Error 对象有一个特定的属性或者用另一种方式来处理 Error 对象的特定属性(例如 Chai的throws断言的做法), 你就得做大量的工作来确保程序的正确运行.同时, 如果抛出的不是 Error 对象, 也就获取不到 stack 属性.

Errors 也可以被作为其它对象, 你也不必抛出它们, 这也是为什么大多数回调函数把 Errors 作为第一个参数的原因. 例如:

const fs = require('fs');
fs.readdir('/example/i-do-not-exist', function callback(err, dirs) {
    if (err instanceof Error) {
        // `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 对象也可以用于 rejected promise, 这使得很容易处理 rejected 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);
    }
});

处理堆栈

这一节是针对支持 Error.captureStackTrace的运行环境, 例如Nodejs.

Error.captureStackTrace 的第一个参数是 object, 第二个可选参数是一个 function.Error.captureStackTrace 会捕获堆栈信息, 并在第一个参数中创建 

stack 属性来存储捕获到的堆栈信息. 如果提供了第二个参数, 该函数将作为堆栈调用的终点. 因此, 捕获到的堆栈信息将只显示该函数调用之前的信息.

用下面的两个demo来解释一下. 第一个, 仅将捕获到的堆栈信息存于一个普通的对象之中:

const myObj = {};
function c() {
}
function b() {
    // Here we will store the current stack trace into myObj
    Error.captureStackTrace(myObj);
    c();
}
function a() {
    b();
}
// First we will call these functions
a();
// Now let's see what is the stack trace stored into myObj.stack
console.log(myObj.stack);
// This will print the following stack to the console:
//    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(被压入堆栈), 然后在 a 里面调用函数 b(被压入堆栈且在a之上), 然后在 b 中捕获到当前的堆栈信息, 并将其存储到 myObj 中. 所以, 在控制台输出的堆栈信息中仅包含了 a和 b 的调用信息.

现在, 我们给 Error.captureStackTrace 传递一个函数作为第二个参数, 看下输出信息:

const myObj = {};
function d() {
    // Here we will store the current stack trace into myObj
    // This time we will hide all the frames after `b` and `b` itself
    Error.captureStackTrace(myObj, b);
}
function c() {
    d();
}
function b() {
    c();
}
function a() {
    b();
}
// First we will call these functions
a();
// Now let's see what is the stack trace stored into myObj.stack
console.log(myObj.stack);
 
// This will print the following stack to the console:
//    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)

当将函数 b 作为第二个参数传给 Error.captureStackTraceFunction 时, 输出的堆栈就只包含了函数 b 调用之前的信息(尽管 Error.captureStackTraceFunction 是在函数 d 中调用的), 这也就是为什么只在控制台输出了 a. 这样处理方式的好处就是用来隐藏一些与用户无关的内部实现细节.

感谢大家阅读本篇文章，之后也会给大家带来关于JS，关于前端的一些小技巧，希望大家共同探讨，一起进步。

相关推荐：

JavaScript和ECMAScript 之间的区别

JavaScript刷新页面location.reload()的用法

JavaScript中正则表达式的含义与使用

The above is the detailed content of A brief analysis of JavaScript error handling and stack tracing. For more information, please follow other related articles on the PHP Chinese website!