What’s the advantage?
Let’s debug in VS Code.
Let’s add breakpoints to the lines where we want our program to stop. Breakpoints will pause the execution of our code. Set them anywhere after an assignment of a variable.
Note: The variables assigned at the breakpoint are not included in the scope.
You can see all the breakpoints set on the bottom-most Run & Debug panel. You can select/deselect them to turn them on/off.
Set Debug Configuration
Note: You can also use the start debug button. You’d have to set the language as node.js and pick the script you’d like to execute.
Running the Program
You can execute the program like you would in your shell. If you’re using the built-in run button, it will ask you to select the script you want to debug.
Evaluating The Results
The program will run until it reaches a breakpoint. At that point, we can start either use the GUI or the Debug Console to see our data.
Using Built-In Debug Console
We can type out the variables that interest us. All the variables you can access are those that are global and local to the scope your breakpoint is in. Variables assigned exactly at the breakpoint won’t be accessible. Tab to autocomplete.
Using the GUI
The left-hand Run & Debug panel shows us variables available in this scope. To see the variables at the next breakpoint, select play.
Debug with Watch
The watch panel monitors expressions throughout our code. If we meet a condition set here, it will evaluate the expression. You can watch a new expression by selecting the + button in the panel and adding the expression.
Sometimes watching variables isn’t enough. Let’s say we want to break only if we meet a condition. To do this, add a normal breakpoint. Then right-click on the breakpoint, select Edit Breakpoint and add your expression.
The call stack is useful for tracing exceptions and seeing who called what. If you want to see who called an item, select the item below it.
This will show you the call.
Bye print statements?
Using the debug console should be another tool in your arsenal to help you debug. Sometimes it can be overkill, but it will often save you time hunting down a bug. It is not a replacement for print statements. Print statements aren’t the best at showing us state, conditional breaking, or more than one variable. It also saves us a lot of scrolling.
Attach the debugger and happy hunting!