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: https://www.youtube.com/watch?v=OBgLeRwjlAc&embedable=true 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. Feature VS Code Comments Links Breakpoint ✅ , Video Post Conditional Breakpoint ✅ , Video Post Logpoint/Tracepoint ✅ , Video Post Step Over ✅ , Video Post Step Into ✅ , Video Post Step Out ✅ , Video Post Continue ✅ , Video Post Run to Cursor ✅ , Video Post Return Immediately ❌ Restart Frame is available , Video Post Jump to Line ❌ , Video Post Return Value Display ✅ (on by default) , Video Post Evaluate ✅ , Video Post Watch ✅ , Video Post Inline Watch ❌ , Video Post Set Value ✅ , Video Post Object Marking ❌ , Video Post Method Breakpoints ❌ , Video Post Field watchpoints ❌ , Video Post Exception Breakpoints ✅ They suck without filters , Video Post Grouping/Naming Breakpoints ❌ , Video Post Disable Breakpoints ✅ , Video Post Instance Filters ❌ , Video Post Class Filters ❌ , Video Post Caller Filters ❌ , Video Post Filtering ❌ Array and Collection filtering , Video Post Stream Debugger ❌ , Video Post Basic rendering ✅ Very simplistic , Video Post Entry Rendering ❌ , Video Post Rendering Annotations ❌ , Video Post Thread View ❌ , Video Post Async Stack Traces ❌ No custom support , Video Post Searchable memory View ❌ , Video Post Track new Instances ❌ , Video Post The Missing Features Following is a high-level overview of the missing features. Flow Control lets us return right away from a method and potentially return an arbitrary value. This is fantastic when you want to test edge cases. Return immediately 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. 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. Jump to line 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 . This is very convenient when watching multiple values. It lets us see the stack at a glance as we scroll through the code. watch variables directly in the editor itself 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. Object marking 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. Method breakpoints are very useful when tracking field mutation and new values. Field watchpoints We can manage breakpoints, 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. name, group 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 , or a . I spent so much time pressing continue over and over again. We can reduce this pain using these tools. instance class specific method in the stack Arrays, Collections and Streams There’s another spectacular type of . 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! filtering 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 borrows concepts from time travel debuggers to make stream debugging easier than regular debugging sometimes. stream debugger Entry Rendering This is one of the most fantastic features you can think of. We can completely . 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. customize the way entries look in the watch But this is hard to configure every time for every case. so we can see this every time for specific library objects when running in the debugger. Annotations let us configure this globally Thread and Asynchronous Debugging VS Code shows threads, but it has very limited display functionality and configurability. IntelliJ can open a , hierarchies and much more. dedicated thread view It also supports 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. gluing asynchronous stack traces together Memory We can search through memory to . We can find VM internal instances and investigate issues by reviewing the objects in the system. find any object instance Better yet. We can . 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. track every new instance of a particular class 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 , , and for videos like the one embedded above. my book my course follow me

Monoliths - Are They Back?

The Dangers and Pitfalls of Remote Debugging: What You Need to Be Careful Of

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Too Long; Didn't Read

The Blind Spots of Debugging in VS Code

The Blind Spots of Debugging in VS Code

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Deep Insight on Memory Debugging

10 Must Have Chrome Extensions for a Web Developer

The Noonification: Can Mankind Survive as an Interplanetary Species? (10/20/2022)

132 Stories To Learn About Performance

3 Golang Pitfalls Every Developer Needs to Know

A Deep Insight on Memory Debugging

10 Must Have Chrome Extensions for a Web Developer

The Noonification: Can Mankind Survive as an Interplanetary Species? (10/20/2022)

132 Stories To Learn About Performance

3 Golang Pitfalls Every Developer Needs to Know

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps