Breakpoints are source code markers used to trigger actions during a debugging session.
IntelliJ IDEA lets you create breakpoints of several types. Each breakpoint type 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.
IntelliJ IDEA enables you to set the following types of breakpoints:
These breakpoints are assigned to lines of source code and are used to target a particular section for debugging.
Temporary line breakpoint
These breakpoints are assigned to 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.
With PHP Exception Breakpoints, you can initiate the debugger at the start of the script and break on your own breakpoints or whenever an error or Exception of a given type occurs. PHP Exception breakpoints do not require configuring Xdebug for working in the Just-In-Time mode by setting
jit, see Debugging in the Just-In-Time Mode for details.
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.
*.html files as well as in
*.php files and are used to target a particular section of code for debugging.
Breakpoints icons and statuses
When a breakpoint is set, the editor displays a breakpoint icon in the gutter area to the left of the affected source code. A breakpoint icon denotes status of a breakpoint, and provides useful information about its type, location, and action.
The icons serve as convenient shortcuts for managing breakpoints. Clicking an icon removes the breakpoint. Successive use of Alt - click on an icon toggles its state between enabled and disabled. The settings of a breakpoint are shown in a tooltip when a mouse pointer hovers over a breakpoint icon in the gutter area of the editor.
The table below summarizes the possible breakpoint states:
|Enabled||Shown at design-time or during the debugging session when the class with such breakpoint is not yet loaded.|
|Valid||N/A||N/A||Shown at run-time when the breakpoint is recognized by the debugger as set on an executable code line.|
|Invalid||N/A||Shown when the breakpoint is set on a commented or non-executable line indicating that such breakpoint would not be hit.|
|Disabled||Indicates that nothing happens when the breakpoint is hit.|
|Conditionally disabled||This state is assigned to breakpoints when they depend on another breakpoint to be activated.|
When the button is pressed in the toolbar of the Debug tool window, all the breakpoints in a project are muted, and their icons become grey: .