Breakpoint settings and debugging techniques for using Chrome to debug JavaScript _javascript tips

How do you debug JavaScript programs? The most original method is to print the content on the page with alert (), and a slightly improved method is to use Console.log () to output the content on the JavaScript console. Well, using both of these methods really solves the problem of debugging a lot of small JavaScript scripts. But it's a shame to have the more powerful developer tools in Chrome. This article mainly describes the JavaScript breakpoint settings and debugging functions, which is the Sources Panel (formerly called Scripts). If you are proficient in the various Java debugging techniques in Eclipse, the concepts are similar here. The Chrome version used when writing this article is 25.0.1364.172.

Basic Environment

Will not shrink back.

At the bottom there are a few feature buttons that are useful.

To set a breakpoint on the source code

With the content source on the left, open the corresponding JavaScript file, the mouse clicks on the file line number can set and delete breakpoints. Each breakpoint that you add appears in the Breakpoints list in the right debug area, and clicking the list breakpoint navigates to the breakpoints on the content area. If you have multiple files, multiple breakpoints, it is convenient to use breakpoints in the Breakpoints list to quickly locate them.

Button temporarily disables all the added breakpoints, and then click Restore Status.

Conditional Breakpoint : Select "Edit breakpoint ..." In the right key menu of the breakpoint location to set the condition that triggers the breakpoint, which is to write an expression that is true to trigger the breakpoint. View the environment call stack for breakpoints: When a breakpoint stops, call stack on the right side of the debug area displays the method call stack at the current breakpoint, such as a function g (), which calls the function f (), and I set a breakpoint in F (), so I'm in the console A breakpoint is triggered when the function g () is executed, and its call stack is displayed as follows:

The top is f (), then G (). Each layer in the call stack is called a frame, and each frame can be clicked to jump to the call point of the frame.

In addition, you can restart the current frame with the right-click menu on the frame, from the beginning of the frame. For example, restart frame on the frame of function f (), the breakpoint jumps to the beginning of f (), and the value of the variable in the context is restored. This combination of variables to modify and edit the code, and other functions, you can repeatedly debug in the current frame, without refreshing the page to trigger the breakpoint again. View variables

Below the call Stack list is the Scope Variables list, where you can view the values of local and global variables at this time. Executing the selected code

button, which is the switch that sets whether an exception is interrupted when the program runs. Click this button to switch between 3 states:

Default encountered exception not interrupted

All exceptions encountered are interrupted, including captured cases

Break only if there is an exception that is not caught

Explain the difference between state 2 and State 3.

try{
Throw ' a exception ';
}catch (e) {
Console.log (e);
}

The code in the try above will encounter an exception, but the following catch code can catch the exception. If all exceptions are interrupted, the code will automatically break when it executes the throw statement that generated the exception, and if it is interrupted only by an unhandled exception, there is no interruption here. In general, we are more concerned about encountering an exception that is not caught.

To set a breakpoint on a DOM element

Sometimes we need to listen for a DOM to be modified without caring what line of code is being modified (and possibly modifying it in many places). Then we can set breakpoints directly on the DOM.

XHR Breakpoint

The right debugging area has a XHR breakpoints, click + and enter the URL contains a string to listen to the URL of the Ajax request, the input content is equivalent to the URL filter. If nothing is filled out, then listen for all XHR requests. Once the XHR call is triggered, it is interrupted at the Request.send () location.

To trigger a breakpoint by event type

The event Listener list for the right debugging area, listing the various possible event types. Tick the corresponding event type, which is interrupted automatically when JavaScript code that triggers the type of event is triggered.

debugging shortcut keys

Shortcuts in all development tools can be found in the settings in the lower-right corner of the interface. Breakpoint debugging is typically used for F8, F10, F11, or shitf+f11, but the function keys such as F10 on Mac OS may conflict with the system's default shortcut key. It does not matter, they can use cmd+/, cmd+ ', cmd+; , shift+cmd+; Replace. @ sourceurl give an eval code sometimes very dynamic code is created in the current Javascript context as a string through the eval () function instead of being loaded as a separate JS file. This way you can't find the file on the left side of the content area, so it's hard to debug. In fact, we can name the code by adding a line to the end of the code that the eval creates (the browser treats this particular form of annotation specifically) so that it appears on the left side of the//@, as if you were loading a named JS file, you can set breakpoints and debug. In the following illustration, we execute a piece of code through eval and use sourceURL to name it dynamicscript.js, and the "file" appears in the left content area after execution, and its contents are the contents of the eval. The button is used to reformat the messy code into beautiful code, such as some compressed JS files can not see the basic, but also unable to debug. Click Format, and then click to cancel Formatting. Before beautifying the
Landscaping references: Chrome Developer Tools Official documentation