IntelliJ IDEA lets you create breakpoints of several types. Each of the breakpoint types supported by IntelliJ IDEA addresses different debugging needs and has its own individual settings.
Breakpoints are triggered when the program reaches the specified line of source code, before it is executed. The line of code that contains a set breakpoint, is marked with a red stripe; once such line of code is reached, the marking stripe changes to blue.
Once set, a breakpoint remains in project until removed. Breakpoints can only be set on executable lines of code. Comments, declarations of fields or methods, and empty lines are not valid locations for breakpoints.
If a file with breakpoints has been modified externally, for example, updated from a version control repository, or changed in an external editor, so that line numbers are changed, then the breakpoints will be moved accordingly.
It is important to note that IntelliJ IDEA should be running at the moment of such modification; otherwise, such changes will pass unnoticed.
In this section:
- Line Breakpoint
- Temporary Line Breakpoints
- Method Breakpoint
- Exception Breakpoint
- Field Watchpoint
These breakpoints are assigned to the lines of source code and are used to target a particular section for debugging.
Temporary line breakpoints
These breakpoints are assigned to the lines of source code and are used to target a particular section for debugging. When hit, such breakpoints are immediately removed.
Method breakpoints act in response to the program entering or exiting a particular method. They let you target your debugging sessions by method you wish to investigate, rather than by line number. Method breakpoints let you follow the program flow at the method level as well as check entry and exit conditions. Note that using method breakpoints can slow down the application you are debugging.
Exception breakpoints are triggered when the specified exception is thrown. Unlike the line breakpoints, which require specific source references, exception breakpoints apply globally to the exception condition, rather than to a particular code reference.
Field watchpoints allow you to react to any access or modification of specific instance variables. For example, if at the end of a complicated process you are ending up with an obviously wrong value on one of your fields, then setting up a field watchpoint may be the quickest way to determine the origin of the fault.