Debugging JS: Part One, "Sources"

Debugging JS Part One -- Sources

Debugging is vital to success in just about any language. Odds are, eventually you'll want to investigate the contents of something or watch the step-by-step execution of your program. I'll show a few of the debugging tools available to the JS programmer in the Chrome console.

There are two main views you'l want to familiarize yourself with for basic debugging: Sources and Console. The former allows you to place breakpoints, watch expressions, and step through code line-by-line like in the Eclipse Java debugging suite. The latter allows you to rapidly test your functions, type safety, and more. Between the two of them and Google, there's virtually no bug in JavaScript you can't solve.

Open the developer tools in Chrome with F12

The first of a three part series.

Part One, "Sources"
Part Two, "Console"
Part Three, "Profiling"

Sources

After opening the developer tools and clicking on sources, you should see something like this:

There are some components of this UI that will be skipped for this basic overview. We'll cover the watch expressions, call stack, scope variables, breakpoints, and the symbolic buttons on the upper right, as well as the source panel itself.

Clicking on the small button in the upper left (the one that looks like a "play button" triangle) should show something like this:

Here, you can browse the document hierarchy. A side benefit of this is that it only has access to the loaded source files, so if you want to check if a .js file is even being loaded, this is a good place to check quickly (or, of course, the html page in question).

Opening a file, we can view it. Next, click the Play/Pause button; the one in the upper left of the right-hand pane of this view, that's highlighted in blue below. This will cause the script to pause (if you have an update loop, as in this example, it is virtually guaranteed to always stop in code that is "close to" the browser-level code. In this case, the code we arrive at after pausing is the function that's used as a callback with the requestAnimationFrame function.

From left to right, the buttons in the cluster with the play/pause button, are the step over, step into, step out, deactivate breakpoints, and pause on uncaught exceptions buttons. You can also use the F-keys to step through the code. Note also the call stack: right now, we're in engine.frame. This can be extremely useful information, knowing where we came from. The scope variables section shows all of the variables visible in the current scope. Breakpoints is empty because we didn't pause on a breakpoint; we just told the code to stop.

Let's create some breakpoints. We can do this by clicking on the line number next to a line of code:

Here, we have two breakpoints. Inside the Breakpoints section, we can see both are "checked". If we uncheck one, it will temporarily disable it without removing it entirely. You can click again on the line number or right click the breakpoint in the breakpoints list to remove it entirely. It works pretty much the same way as it does in a proper IDE.

Here's adding a couple of variables to watch in the watch expressions panel:

Note that the difference between a watch expression and a scope variable is that you can make a watch expression be anything. This means you can "tunnel" several layers deep, like watching foo.bar.goo.gah.boof.x, or evaluating a function, like watching the return value of foo(x,y). Note that, if you have side effects of functions, odd behavior may occur, so use this technique with some amount of caution!

Finally, if you click the "show/hide drawer" button (highlighted in blue below), you can have your console and search bars show up inside the sources pane. If you have the screen real estate for it, I recommend doing debugging in this way.

Next up: We look at the Console functionality, learn how to write code on the fly and insert it into our application, and use the console to test code!