Debugging Javascript — Part 1: Sources

Intro

...
...
console.log(input)
x = calculateX(input);
console.log(x);
if (something) {
console.log('inside');
} else {
console.log('outside');
}
...
...
1.232
23232
outside

Breakpoints

Screenshot of a file from google.com
Active breakpoint on line 13 — Screenshot from google.com
Conditional Breakpoint — Screenshot from google.com

Variable Inspection

Variable Inspection through hovering — Screenshot from google.com
Scopes section — Screenshot from google.com
Watch Section — Screenshot from google.com

Call stack Inspection

Call Stack Section — Screenshot from google.com

Navigation options

Breakpoint resume options — Screenshot from google.com
function updateHeader() {
const name = getName(); // A
const x = 1; // D
}
function getName() {
const name = `${app.first} ${app.last}`; // B
return name; // C
}
  1. The most common option would be to simply click on the “play” icon and everything will continue as normal until another breakpoint is encountered. This option is marked with a red circle in the screenshot above. In our example, supposing that no other breakpoint exists on lines B, C and D, then the code will never pause again.
  2. Another option would be to simply resume execution “line by line”. This is useful in situations where you are “paused” on a line of code containing a function that’s not relevant to the problem you’re debugging and you want to execute the function without stepping into it. By clicking on this option (marked with a blue circle in the screenshot above) you will resume the execution for whatever happens on the line and then the thread will “pause” again. In the code above, the thread (which is currently paused on A) will pause on D when this button is clicked.
  3. If the line does contain relevant code though, then you can step into it, by clicking on the button with the “arrow-down” icon (marked with a green circle in the screenshot above). This is useful in scenarios where further investigation is needed on how an output got calculated. In the example above, the thread (which is currently paused on A) will pause on B, C and D supposing you keep clicking the button.
  4. In cases where a particular function you’ re inspecting is too big, you can step out of it and pause again. This is useful in scenarios where you have already stepped into a function (with the previous navigation option) and you’ re like “ok, i’m done with that”. To understand that, suppose you are paused on A, then you click the navigation option № 3. This would pause the thread on B. If getName was too big of a function you could click “step out” and instead of going to C, you would instantly go to D.
  5. If you got sick of all these navigation options, then good news! You can press on the “Deactivate breakpoints” switch (marked with a purple circle in the screenshot above) and you will disable all breakpoints until you press on it again. No matter how many more breakpoints you add, nothing will happen as long as this switch is active. This is very helpful in scenarios where you have a lot of breakpoints in different files and you don’t want to erase them, but simply de-activate them for a while, because you have been overran by “pauses” and no matter how many times you keep pressing the “play” button, there always is another breakpoint that “pauses” the app.
    This is the perfect place to mention that all of your breakpoints will always be visible in the Breakpoints Section on the right sidebar. From there, you can enable, disable or remove them in a more fine-grained fashion. Just right-click on one of them and you’ll see all the available options.
  6. Lastly, the most interesting switch of them all is the “pause on exceptions” button. This will add a breakpoint automatically whenever a Javascript exception occurs. This is helpful in scenarios where your code throws an exception, but you’ re not fully aware of what’s causing it. Having this switch active (marked with an orange circle in the screenshot above) can help you out identify the problematic piece of code.
    These automatic breakpoints are in fact an interesting feature of the dev tools. You can tell the system to automatically add breakpoints whenever a request to a particular URL is sent (check out XHR/Fetch Breakpoints Section) or whenever a particular event occurs like clicks & hovers (check out Event Listener Breakpoints). The latter can be extremely helpful when debugging your logging mechanisms, but because this article series aims to familiarise people with debugging, we won’t be focusing on these advanced uses. Just thought we should mention them, so you know that these features exist.

Closing Notes

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store