In this section:
|Item||Tooltip and shortcut||Description|
|Click to show the list of available breakpoint types. Select the desired type to create a new breakpoint.|
|Remove Breakpoint||Click this button to remove selected breakpoints.|
|Group by Package||Click this button to display breakpoints under their respective packages, rather than under their types:|
|Group by File||Click this button to display breakpoints under their respective files, rather than under their types:|
|Group by Class||Click this button to display breakpoints under their respective classes, rather than under their types:|
The controls of this part of the Breakpoints dialog depend on the type of the selected breakpoint.
|Option||Description||Types of breakpoints|
|Suspend||Select this check box to enable suspend policy for a breakpoint. |
If the check box is not selected, no threads are suspended.
|Condition|| Select this check box and specify a condition for hitting a breakpoint in the text field. |
A condition is a Java Boolean expression (including a method returning
This expression should be valid at the line where the breakpoint is set, and is evaluated every time the breakpoint is reached. If the evaluation result is
If the result is
Conditions for field/method/exception breakpoints are calculated in the context for the given field/method/exception.
To the right of the Condition field, there is the button (Shift+Enter) that opens the multiline editor.
Thus it's possible to enter multiline expressions, for example:
|Log message to console||Select this check box if you want a log message to be displayed in the console output when the breakpoint is hit.||All types|
|Evaluate and log||Select this check box if you wish to evaluate a certain expression at this breakpoint and to export result to the console output. |
To the right of this field, there is the button (Shift+Enter) that opens the multiline editor.
If the expression to be evaluated is incorrect when a particular breakpoint is reached, the console output displays an error message:
|Remove once hit||Select this check box, if the you want the breakpoint to be deleted after hitting it.||All types|
|Disabled until selected breakpoint is hit||From the drop-down list, select the breakpoint in question. The option None corresponds to the always enabled breakpoint. |
Besides that, you can also choose the behavior of this breakpoint, when the selected one is hit:
|Catch class filters||Select this check box if you want to filter out where the exceptions are caught. |
Define a catch class filter in two ways:
For example, the filter
|Instance filters||An instance filter is used to limit breakpoint hits only with particular object instances using instance IDs. The instance ID value can be introduced manually or using the Instance Filters dialog box called by clicking the ellipsis button. Existing instance filters are indicated by the instance ID delimited with spaces.||Line/Exception/Field/Method|
|Class filters||Select this check box to have the breakpoint behave differently in relation to particular classes. |
Define the class filter to appoint the classes where you want the breakpoint to be hit and the classes where the breakpoint should not be triggered.
Classes in a filter can be identified by their names or by means of class patterns.
A class pattern is a string that may start or end with an asterisk (*). The asterisk in a pattern means any number (including zero) of any characters. The patterns are matched against fully qualified class names.
The breakpoint behavior is different in relation to classes specified by their names or using class patterns.
A filter specified through a class name points at the class itself as well as at all its subclasses (i.e. the classes directly or indirectly extending this one).
A filter specified through a class pattern points at the classes whose fully qualified names match the pattern. The subclasses of such classes are selected only if their fully qualified names also match the specified pattern.
You can define a class filter in two ways:
|Pass count|| Specify the integer number, on which hit of the breakpoint it should be triggered. After the specified number of passes, the breakpoint is hit. |
This function is helpful for debugging loops or methods called several times. When the execution process comes to a breakpoint, where Pass count is set, the debugger reduces the count value by 1 and compares it to zero. If the comparison result is
The Pass count condition can be satisfied only once. In other words, if you have a loop inside a method and the Pass count condition has been honored once, the breakpoint will not be hit the next time the said method is called.
This option is only enabled, when Condition, Instance filters and Class filters options are disabled.
|Field access||Stands for triggering breakpoint every time the field is accessed.||Field watchpoints|
|Field modification||This check box is selected when simple read attempts shouldn't cause the breakpoint to trigger.||Field watchpoints|
|Method entry||Stands for triggering breakpoint every time the method is entered.||Method breakpoints|
|Method exit||Stands for triggering breakpoint every time the method is exited.||Method breakpoints|
|Caught exception/Uncaught exception||Specify in which cases you will be notified about hitting an exception breakpoint.||Exception breakpoints|
Context menu commands
Speed search of a breakpoint
To find a particular breakpoint
- Start typing address or description of the target breakpoint:
IntelliJ IDEA highlights the line with the matching address or description.