If your browser supports debugging, you can use console.log() to display JavaScript values in the debugger window:
<!DOCTYPE html>
<html>
<body>
<h1>My First Web Page</h1>
<p>
Activate debugging in your browser (Chrome, IE, Firefox) with F12, and select "Console" in the debugger menu.
</p>
<script>
a = 5;
b = 6;
c = a + b;
console.log(c);
</script>
</body>
</html>
var x = 15 * 5;
debugger;
document.getElementbyId("demo").innerHTML = x;
Normally, you activate debugging in your browser with F12, and select "Console" in the debugger menu.
Otherwise follow these steps:
Note: If you are a Web Developer and want to get the latest version of DevTools, you should use Chrome Canary.
The Sources panel lets you debug your JavaScript code. It provides a graphical interface to the V8 debugger. Follow the steps below to explore the Sources panel:
Open a site such as the TodoMVC Angular app.
Open the DevTools window.
If it is not already selected, select Sources.
The Sources panel lets you see all the scripts that are part of the inspected page. Standard controls to pause, resume, and step through code are provided below the panel selection icons. A button to force a pause at exceptions is located at the bottom of the window. Sources are visible in separate tabs and clicking opens the file navigator which will display all open scripts.
The execution control buttons are located at the top of the side panels and allow you to step through code. The buttons available are:
There are also several related keyboard shortcuts available in the Sources panel:
For a walkthrough of other keyboard shortcuts supported, see Shortcuts.
A breakpoint is an intentional stopping or pausing place in a script. Use breakpoints in DevTools to debug JavaScript code, DOM updates, and network calls.
In the Sources panel, open a JavaScript file for debugging. In the example below, we are debugging the todoCtrl.js file from the AngularJS version of TodoMVC.
Click the line gutter to set a breakpoint for that line of code. A blue tag will indicate if a breakpoint has been set:
You can add multiple breakpoints. Click the line gutter of another line to set another breakpoint. All the breakpoints you have set appear under Breakpoints in the right-hand sidebar.
Breakpoints can be enabled or disabled using the checkboxes in this sidebar. If a breakpoint is disabled, the blue tag will appear faded out.
Click on a breakpoint entry to jump to that particular line in the source file:
Remove a breakpoint by clicking the blue tag breakpoint indicator.
Right-click on the blue tag to access a menu with several options including: Continue to Here, Remove Breakpoint, Edit Breakpoint, and Disable Breakpoint.
To set a conditional breakpoint, choose Edit Breakpoint. Alternatively, right-click on the gutter line and choose Add Conditional Breakpoint. In the input field, type any expression that could resolve to true or false. The breakpoint will pause code execution only if the condition is true.
Conditional breakpoints are especially useful when you're looking to analyze code in a loop or an event callback that fires often.
Note: It may not be desirable to set breakpoints from the DevTools interface. Should you wish to launch the debugger from your code, you may use the debugger keyword to achieve this.
Once you have one or more breakpoints set, return to the browser window and interact with your page. In the example below, a breakpoint was added within removeTodo(). Now any attempts to delete a todo item in the TodoMVC app will trigger a breakpoint pause:
To resume code execution, click the
Continue button or use the
F8 keyboard shortcut in the DevTools window.
While a script is paused, you can interact with the Watch Expressions, Call Stack, and Scope Variables panels in the right-hand side bar.
The Call Stack panel displays the complete execution path that led to the point where code was paused, giving us insights into the code flaws that caused the error.
To view the execution path including asynchronous JavaScript callbacks such as timer and XHR events, check the Async checkbox.
Further information and examples using async call stacks can be found in Debugging Asynchronous JavaScript with Chrome DevTools on HTML5Rocks.com.
The DevTools console drawer will allow you to experiment within the scope of where the debugger is currently paused. Hit the Esc key to bring the console into view. The Esc key also closes this drawer.
onMouseOver
function
raiseException
functionappendChild
function callsend
function callNote: To edit URL filter, double click on the XHR breakpoint entry in XHR Breakpoints sidebar pane. XHR breakpoint with empty URL filter will match any XHR.
Let's now look at how to deal with exceptions and stack traces using Chrome DevTools.
Exception handling is the process of responding to the occurrence of exceptions - exceptional situations that require special processing - often changing the normal flow of your JavaScript code's execution.
Note: If you are a Web Developer and want to get the latest version of DevTools, you should use Chrome Canary.
When something goes wrong, you can open the DevTools console (Ctrl+Shift+J / Cmd+Option+J) and find a number of JavaScript error messages there. Each message has a link to the file name with the line number you can navigate to.
There might be several execution paths that lead to the error and it's not always obvious which one of them has happened. Once DevTools window is opened, exceptions in the console are accompanied with thecomplete JavaScript call stacks. You can expand these console messages to see the stack frames and navigate to the corresponding locations in the code:
You may also want to pause JavaScript execution next time exception is thrown and inspect its call stack, scope variables and state of your app. A tri-state stop button ( ) at the bottom of the Scripts panel enables you to switch between different exception handling modes: you can choose to either pause on all exception or only on the uncaught ones or you can ignore exceptions altogether.
Printing log messages to the DevTools console may be very helpful in understanding how your application behaves. You can make the log entries even more informative by including associated stack traces. There are several ways of doing that.
Each Error object has a string property named stack that contains the stack trace:
You can instrument your code with console.trace() calls that would print current JavaScript call stacks:
There is also a way to place assertion in your JavaScript code. Just call console.assert() with the error condition as the first parameter. Whenever this expression evaluates to false you will see a corresponding console record:
Chrome supports setting a handler function to window.onerror. Whenever a JavaScript exception is thrown in the window context and is not caught by any try/catch block, the function will be invoked with the exception's message, the URL of the file where the exception was thrown and the line number in that file passed as three arguments in that order. You may find it convenient to set an error handler that would collect information about uncaught exceptions and report it back to your server.