Setting Breakpoints in IntelliJ IDEA
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
A breakpoint is a debugging tool that pauses your program at a specific line so you can inspect what's happening.
You click in the margin next to a line number in your IDE, and a red dot appears. When your code runs and reaches that line, execution stops right before that line executes. At that moment, you can see all the variable values in the Variables panel, examine the call stack to understand how you got there, and even evaluate custom expressions to test theories about what's wrong.
I've used breakpoints extensively when debugging calculation errors in my university projects.
For example, if a total price calculation is wrong, I'd set a breakpoint right before the calculation line, run the code, and when it pauses I can see the input values going into the calculation. That immediately shows me if the problem is bad input data or wrong calculation logic.
One thing freshers often miss is conditional breakpoints—if you're debugging a loop that runs 500 times but only fails on iteration 437, you can right-click the breakpoint and add a condition like i equals 437. That way the debugger only pauses on that specific iteration instead of making you hit Continue 436 times.
The key is breakpoints let you freeze time in your program and examine everything without changing your code or adding print statements everywhere.
Setting Breakpoints in IntelliJ IDEA
Direct Answer
A breakpoint is a marker you place on a line of code in your IDE that pauses program execution when that line is reached. The debugger stops there so you can inspect variables, evaluate expressions, and understand what the program is doing at that exact moment.
Code Example
@Service
public class OrderService {
private final OrderRepository repository;
private final PriceCalculator calculator;
public OrderService(OrderRepository repository, PriceCalculator calculator) {
this.repository = repository;
this.calculator = calculator;
}
public Order processOrder(Long orderId) {
var order = repository.findById(orderId).orElseThrow();
// Set breakpoint here to inspect order state
var discount = calculator.calculateDiscount(order);
order.setDiscount(discount);
// Set another breakpoint here to verify discount was applied
var total = calculator.calculateTotal(order);
order.setTotal(total);
return repository.save(order);
}
}
Common Mistakes & Pitfalls
- Setting breakpoints in the wrong place: freshers often set breakpoints on exception-throwing lines, but by then it's too late—the bad data already exists. Set breakpoints earlier where the problematic data is created.
- Not using conditional breakpoints for loops: placing a regular breakpoint inside a loop that runs 1000 times means hitting Continue 999 times manually. Use a conditional breakpoint with i == 500 to pause only on the problematic iteration.
- Forgetting to remove breakpoints: leaving dozens of old breakpoints active slows down debugging and causes confusion when the program pauses at unexpected places you set days ago.
Check your understanding
Answer these without looking back at the article.
- What is a watch expression in a debugger?
- How do you debug a Spring Boot application in IntelliJ?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.