The Blind Spots of Debugging in VS Code

In the first chapter of my debugging book, I discuss IDE debugging. In that chapter, I mostly talk about IntelliJ/IDEA. People often ask me why I didn’t write as much about VS Code… The reason is that there isn’t much to write about. Its debugger is simpler for better and for worse. It isn’t as powerful as other IDEs. I created the following video that covers the content of this post:

This isn’t a slam against VS Code or against Microsoft. Visual Studio has one of the most powerful debuggers around. But Visual Studio Code doesn’t have a lot of the features from Visual Studio or other IDEs. I believe this is intentional. I think this is a user experience-driven decision in which they removed features to simplify usability. One thing VS Code did well was exposing the logpoint (tracepoint) feature, so it is more discoverable to the casual developer. That’s pretty great and wouldn’t have been practical if the IDE had all the salient features.

But there’s a price that comes with simplicity. As you can see in the following table, there are many missing features that are available in IntelliJ. These are all features I covered in blog posts or videos. Notice that the video links in the following table are direct links to the specific time within the video.

The Missing Features

Following is a high-level overview of the missing features.

Flow Control

Return immediately lets us return right away from a method and potentially return an arbitrary value. This is fantastic when you want to test edge cases.

There are also drop frame and throw exception features.

To be fair, VS Code has “restart frame” which is similar to “drop frame” and also nice.

Jump to line requires a plugin for IntelliJ. It lets us drag the execution pointer to an arbitrary location. If you have a bug, just drag the execution back and try again.

Need to skip a line of code because your app is in a problematic state, but you still want to debug?

Drag forward. This is a fantastic killer feature when you need it.

Watch Area

Both IDEs contain a watch, but only IntelliJ can show the values of the watch variables directly in the editor itself. This is very convenient when watching multiple values. It lets us see the stack at a glance as we scroll through the code.

Object marking is one of my favorite obscure features. It lets us dynamically declare a global variable that helps us track a value. We can use this global variable in a conditional breakpoint to verify things. One such example is saving the current thread as a marked object and then only breaking if we hit the method with a different thread.

Breakpoints

Method breakpoints are pretty problematic, but they have some edge uses. One of the big values is the ability to break when returning from a long method. This is helpful in tracing threading issues.

Field watchpoints are very useful when tracking field mutation and new values.

We can manage breakpoints, name, group and disable them as a hierarchy group. When dealing with multiple tasks and switching branches in the middle of a debugging session, we can keep that session on hold by grouping all the breakpoints together.

When we return to the task, we can instantly jump right back!

VS Code has exception breakpoints. But without filters, they absolutely suck!

We can filter breakpoint hits based on multiple criteria such as instance, class or a specific method in the stack. I spent so much time pressing continue over and over again. We can reduce this pain using these tools.

Arrays, Collections and Streams

There’s another spectacular type of filtering. We can filter the content of an array or collection right in the watch or evaluate area. I spent a great deal of time digging through arrays of image data with thousands of elements. This was a nightmare. With this, we can find the entries that we need in a collection or array, instantly!

This is about the Java 8 and newer stream API, which is a functional programming construct. It’s a fantastic tool, but it makes debugging awkward. The stream debugger borrows concepts from time travel debuggers to make stream debugging easier than regular debugging sometimes.

Entry Rendering

This is one of the most fantastic features you can think of. We can completely customize the way entries look in the watch. In the demo here, I show how I can expose the content of an Object Relational Mapping object as I step over in the debugger.

But this is hard to configure every time for every case. Annotations let us configure this globally so we can see this every time for specific library objects when running in the debugger.

Thread and Asynchronous Debugging

VS Code shows threads, but it has very limited display functionality and configurability. IntelliJ can open a dedicated thread view, hierarchies and much more.

It also supports gluing asynchronous stack traces together to make it easier to debug asynchronous code. This works seamlessly with well-known APIs and the really cool thing is that we can use annotations to add this to our custom APIs.

Memory

We can search through memory to find any object instance. We can find VM internal instances and investigate issues by reviewing the objects in the system.

Better yet. We can track every new instance of a particular class. Get full stack traces to every new instance created between one breakpoint and another. This can track what happened under the hood with surgical precision.

Finally

There’s a lot I didn’t cover because there’s just so much. I don’t think VS Code is inherently bad. It just went for simplicity. Personally, I think of myself as a power user. If you’re like me, I hope this post gave you a sense of what you’re missing.

Please check out my book, my course, and for videos like the one embedded above.