Your code compiles and runs, but the output is wrong. System.out.println() can help, but you have to add print statements everywhere, then remember to remove them later.
The debugger is a better way. It lets you:
- Pause your program at any line you choose
- Inspect every variable and its current value
- Step through your code one line at a time
- Find exactly where things go wrong
Think of it like slow-motion replay for your code. Instead of guessing, you watch what happens.
A breakpoint tells the debugger: "pause here before executing this line."
- To set a breakpoint: Click in the gutter (the gray area to the left of the line numbers). A red dot appears.
- To remove it: Click the red dot again.
- You can set multiple breakpoints — the debugger will pause at whichever one it hits first, then again at the next one when you resume.
- Shortcut: Ctrl+F8 ⌘+F8 — toggles a breakpoint on the current line
Instead of clicking the green Play button (Run), click the Bug icon next to it (Debug).
- Shortcut: Shift+F9 ⌃+D
- Your program runs normally until it hits a breakpoint, then pauses.
- The current line is highlighted (usually in blue/green) — this line has not executed yet.
- The Debug tool window opens at the bottom of IntelliJ.
| Action | Shortcut | What It Does |
|---|---|---|
| Step Over | F8 F8 | Execute the current line, then move to the next one. If the line calls a method, run the whole method without stepping into it. |
| Step Into | F7 F7 | If the current line calls a method, jump inside that method to debug it line by line. If no method call, behaves like Step Over. |
| Step Out | Shift+F8 ⇧+F8 | Finish running the rest of the current method and return to the caller. Use this when you accidentally stepped into a method you don't care about. |
| Resume | F9 ⌘+⌥+R | Continue running the program until the next breakpoint is hit (or the program ends). |
| Stop | Ctrl+F2 ⌘+F2 | Kill the program immediately. Use when you've found the bug and don't need to keep running. |
System.out.println()). Use Step Into when a line calls your method and you want to see what happens inside it. Use Step Out when you're done inspecting a method and want to go back.
When the debugger pauses, the Debug tool window opens at the bottom of IntelliJ with three key areas:
📊 Variables Panel
Shows all variables in the current scope with their current values. Updates every time you step. You can expand objects to see their fields. This is where you'll spend most of your time.
📚 Call Stack
Shows the chain of method calls that led to the current line (e.g., main → calculateTotal → applyDiscount). Click any frame to see its local variables.
📝 Evaluate Expression
Type any Java expression and evaluate it in the current context. Great for testing "what if" scenarios without changing your code. Open with Alt+F8 ⌥+F8
- "Always Debug instead of Run" — Get in the habit. If nothing goes wrong, it behaves exactly the same. But when something does go wrong, you're ready.
- Set breakpoints BEFORE the suspect line — The debugger pauses before executing the breakpoint line. Set it a line or two before where you think the bug is.
- Watch variable values change as you step — If a value becomes wrong after a specific step, that line is your culprit.
- Use Step Over for lines you trust — Don't step into
System.out.println()orscanner.nextInt(). Step over them. Only step into your own methods. - Hover over variables in the editor — No need to look at the Variables panel every time. Just hover over a variable name and IntelliJ shows its value.
- Don't be afraid to set lots of breakpoints — They cost nothing. Set one at the start of a method, another inside a loop, another after a calculation. Remove them when you're done.
1 "My calculation is wrong"
Set a breakpoint before the calculation. Step over the line. Check each variable in the Variables panel — which value isn't what you expected?
2 "My if/else goes to the wrong branch"
Set a breakpoint on the if line. When it pauses, hover over the condition or check the Variables panel — is the condition true or false? That tells you why it went where it did.
3 "My loop runs too many/few times"
Set a breakpoint inside the loop body. Each time it pauses, check the loop counter and the condition. Watch how the counter changes on each iteration.
4 "NullPointerException"
Set a breakpoint a few lines before the crash. Step through line by line. Check each variable — find the one that's null when it shouldn't be. Then trace back to where it was supposed to be set.