Debugging Java Code: Techniques and Tools for Pros

Debugging Java Code: From "Why doesn't it work?" to "I'm in control"

Every Java developer knows this feeling: you run the application, it crashes with a NullPointerException, and the stack trace leads nowhere. Or, even worse, the code runs but produces completely unexpected results. Sound familiar? Welcome to the world of debugging. It's not just about finding bugs—it's the art of understanding what your program is actually doing.

In this article, we'll break down how to debug Java code like a pro. You'll learn advanced techniques that will save you hours of frustration, and tools that will turn debugging from a chore into an exciting detective story. Let's go!

1. The Basics: Breakpoints — Your Best Friend

Let's start with the most obvious: breakpoints. But don't skip ahead—you'd be surprised how many developers only use 10% of their capabilities.

1.1. Line, Conditional, and Exception Breakpoints

In IntelliJ IDEA (and other modern IDEs), there are three basic types:

\n
• Line breakpoint — placed on a line of code. The program stops every time it reaches that line.
\n
• Conditional breakpoint — you set a condition (e.g., i == 5). The program will only stop when the condition is true. This is a lifesaver in loops with millions of iterations.
\n
• Exception breakpoint — catches the moment when a specific exception is thrown (e.g., NullPointerException). It's placed not on a line, but on the error type. Very useful if the exception occurs somewhere deep in a library.
\n

Example of setting a conditional breakpoint:

public class Main {\n    public static void main(String[] args) {\n        for (int i = 0; i < 100; i++) {\n            // Set breakpoint, condition: i == 42\n            System.out.println("Iteration: " + i);\n        }\n    }\n}

When the loop reaches the 42nd iteration, the debugger will stop. The other 99 times it will fly by without stopping.

1.2. Watchpoints: Tracking Fields

Need to know who and when changes a field's value? Use a watchpoint. You place it on a class field, and the debugger stops every time that field is read or written.

public class User {\n    private String name; // Place a watchpoint on this field\n\n    public void setName(String name) {\n        this.name = name; // Stops here\n    }\n\n    public String getName() {\n        return name; // Or here, if read mode is enabled\n    }\n}

2. Java Debugging Tools: What Should Be in Your Arsenal

The good news: you don't need third-party utilities if you have a modern IDE. But knowing their capabilities is essential.

2.1. IntelliJ IDEA Debugger: Hidden Features

Here are a few features that make debugging Java code a pleasure:

\n
• Drop Frame (the down-arrow button) — allows you to "roll back" execution to the previous method in the call stack. You don't change the program's state, but you can re-run the logic. Indispensable when you've missed a step.
\n
• Evaluate Expression (Alt+F8) — you can execute any code right during debugging. Want to know what list.size() returns? Or even change a variable's value on the fly? Go ahead.
\n
• Hot Swap — changed a method and want to test it without restarting? IntelliJ IDEA supports hot swapping of classes. It doesn't work for all changes (e.g., you can't add a new field), but for method bodies, it's perfect.
\n

2.2. Alternatives: Eclipse, VS Code, and JDB

If you use Eclipse, there are similar features: Display view for expressions and Drop to Frame. In VS Code with Java Ex