Shulou(Shulou.com)06/01 Report--

This article Xiaobian detailed introduction of "IE10 Error.stack script debugging methods", detailed content, clear steps, details handled properly, I hope this "IE10 Error.stack script debugging methods" article can help you solve doubts, following the editor's ideas slowly in-depth, together to learn new knowledge.

Debug the application

Structured error handling in JavaScript relies on throw and try/catch, where the developer declares an error and passes the control flow to some part of the program that handles the error. When an error is thrown, the Chakra, the JavaScript engine in Internet Explorer, captures the call chain that caused the error, a process also known as the call stack. If the object being thrown is an Error (or a function whose prototype chain will cause Error), Chakra creates a stack trace, a list of calls that can be read manually. The list will be represented as an attribute, the stack in the Error object. Stack contains the error message, the name of the function, and the source file location information for the function. This information will help developers understand the functions being called and even look at the wrong lines of code to diagnose defects quickly. For example, this information may indicate that a parameter passed to the function is empty or is of an invalid type.

Let's take a look at a simple script and discuss it in depth. The script attempts to calculate the distance between (0,2) and (12,10) points:

Copy the code

The code is as follows:

(function () {

'use strict'

Function squareRoot (n) {

If (n < 0)

Throw new Error ('Cannot take square root of negative number.')

Return Math.sqrt (n)

}

Function square (n) {

Return n * n

}

Function pointDistance (pt1, pt2) {

Return squareRoot ((pt1.x-pt2.x) + (pt1.y-pt2.y))

}

Function sample () {

Var pt1 = {x: 0, y: 2}

Var pt2 = {x: 12, y: 10}

Console.log ('Distance is:' + pointDistance (pt1, pt2))

}

Try {

Sample ()

}

Catch (e) {

Console.log (e.stack)

}

) ()

The script contains a flaw that does not adjust the differences between components. Therefore, for some inputs, the pointDistance function will return the wrong result; in other cases, the script will cause an error to occur. To understand the meaning of the stack trace, let's look at the errors in the F12 developer tool and look at its scripting tab:

The F12 developer tool in the screenshot shows a stack trace recorded by the call console.log (e.stack), where e is the error object passed to the catch clause in the try/catch data block.

The stack trace is dumped to the console in the catch clause, and because it is at the top of the stack, errors originating from the squareRoot function will become obvious. To debug this problem, developers do not need to drill down into the stack trace; the system has violated the precondition of squareRoot and only needs to look one level up the stack, and the reason becomes clear: the subexpression within the squareRoot call should itself be an argument to square.

During debugging, the stack property will help identify the code used to set the breakpoint. Remember: you can also use other methods to view the call stack: for example, if you set the script debugger to break by catching an exception, you can use the debugger to check the call stack. For deployed applications, consider merging the problem code within try/catch to capture failed calls and record them on the server. The developer can then view the call stack to isolate the problem area.

DOM exception and Error.stack

Previously, I have noticed that the object being thrown must be Error or cause Error through its prototype chain. This is intentional; JavaScript can support throwing any object, even as an exception primitive. Although all these objects can be captured and checked by the system, their full use does not contain errors or diagnostic information. Therefore, only the wrong stack property will be updated during the throw.

Even if the objects are DOM exceptions, they do not contain the prototype chain that can cause Error, so they will not contain the stack property. In some application scenarios where you need to perform DOM operations and want to expose JavaScript compatibility errors, you may want to merge your DOM operation code in the try/catch data block and raise a new Error object in the catch clause:

Copy the code

The code is as follows:

Function causesDomError () {

Try {

Var div = document.createElement ('div')

Div.appendChild (div)

} catch (e) {

Throw new Error (e.toString ())

}

}

However, you may want to consider whether to use this pattern. This is probably the best pattern for utility library development, especially when you consider whether the code is intended to hide DOM operations or simply perform a task. If the goal is to hide the DOM operation, then merging the operation and raising the Error may be the right way to choose.

Performance consideration

The construction of a stack trace begins when the error object is thrown; to construct a stack trace, you need to look at the current execution stack. To prevent performance problems (and even possible recursive stack chains) during traversing large stacks, IE collects only the top ten stack frames by default. However, this setting can be configured by setting the static property Error.stackTraceLimit to another value. This setting is global and must be changed before an error is raised, otherwise it will have no effect on the stack trace.

Asynchronous exception

When a stack is generated by an asynchronous callback (such as timeout, interval, or XMLHttpRequest), the asynchronous callback (rather than the code created by the asynchronous callback) is located at the bottom of the call stack. This will have some potential impact on tracking problematic code: if you use the same callback function for multiple asynchronous callbacks, it will be difficult for you to determine which callback caused the error by checking separately. Let's modify the previous example slightly. We will avoid calling sample () directly, and instead put it in the timeout callback:

Copy the code

The code is as follows:

(function () {

'use strict'

Function squareRoot (n) {

If (n < 0)

Throw new Error ('Cannot take square root of negative number.')

Return Math.sqrt (n)

}

Function square (n) {

Return n * n

}

Function pointDistance (pt1, pt2) {

Return squareRoot ((pt1.x-pt2.x) + (pt1.y-pt2.y))

}

Function sample () {

Var pt1 = {x: 0, y: 2}

Var pt2 = {x: 12, y: 10}

Console.log ('Distance is:' + pointDistance (pt1, pt2))

}

SetTimeout (function () {

Try {

Sample ()

}

Catch (e) {

Console.log (e.stack)

}

}, 2500)

) ()

Once this code snippet is executed, you will notice a slight delay in the stack trace. At this point, you will also find that the bottom of the stack is not global code, but Anonymous function. In fact, this is not the same anonymous function, but a callback function passed to setTimeout. Because you have lost the context associated with suspending the callback, you may not be able to determine what the callback was called. If, in an application scenario, the system registers a callback to handle click events for many different buttons, you will not be able to tell which callback the registration will refer to. Having said that, this limitation is limited, after all, because in most cases, the top of the stack may highlight the problem area.

Read this, the "IE10 Error.stack script debugging methods" article has been introduced, want to master the knowledge of this article also need to practice and use to understand, if you want to know more about the article, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.