Buttons
| Item | Breakpoint type | Description |
|---|---|---|
| Tree View / List View | Line/ Method/ Exception/ Field Watchpoint | Click to toggle between tree view and list view. |
| Add | Field Watchpoint/ Exception/ Method | Click to create new breakpoint. |
| Go to | All but Exception | Navigates to the selected breakpoint, positions the caret at the corresponding line and closes the dialog box. |
| View Source | All but Exception | Pressing this button does the same as the Go to button (navigates to the code page containing the selected breakpoint, positioning the caret in the appropriate line) except that the dialog remains open. |
| Remove | All | Removes selected breakpoints. If all breakpoints are removed from the list, the lower pane would have no selection groups available and all buttons except for Close would be disabled. |
Grouping options
Use these check boxes to rearrange the breakpoints tree.
| Item | Breakpoint type | Description |
|---|---|---|
| Group by methods | Line | If checked, breakpoints in a class are shown inside corresponding methods. |
| Group by classes | Line/ Method/ Field Watchpoint/ Exception | If checked, breakpoints are shown inside corresponding classes. |
| Group by file |
The following is available only in the Ultimate edition of IntelliJ IDEA Flex/ JavaScript |
If checked, breakpoints are shown inside corresponding files. |
| Flatten packages | Line/ Method/ Field Watchpoint/ Exception | If checked, all packages are displayed as a single-level tree view. |
Suspend policy
For Line/ Method/ Exception breakpoints and Field Watchpoints select one of the radio buttons to specify the way the running of the program is paused when a breakpoint is reached. If you work with Flex or JavaScript breakpoints you only need to specify whether you want to suspend program execution when the breakpoint is hit.
Note
This feature is useful, for instance, to create a master breakpoint, which being hit, enables lots of dependent ones. Another way to use is to obtain logging information or calculate some expression at a certain point (to be shown in the console) not interrupting the program execution.
| Item | Description |
|---|---|
| All | When the breakpoint is hit, all threads are suspended. |
| Thread | When the breakpoint is hit, the thread where the breakpoint is hit is suspended. |
| None | No thread is suspended. |
Actions
| Item | Breakpoint type | Description |
|---|---|---|
| Log message to console | All types | Select this check box if you want a log message to be displayed in the console output when the breakpoint is hit. |
| Log evaluated expression | All | Select this check box if you wish to evaluate a certain expression at this breakpoint and to export
result to the console output.
Tip If the expression to be evaluated is incorrect when a particular breakpoint is reached, the console output displays an error message: Unable to evaluate the expression <your_expression>. |
| Depends on | All |
Here you can set a breakpoint the current one will depend on.
Thus the dependent, slave breakpoint is conditionally disabled - it becomes enabled only if the master breakpoint is hit. Moreover, after the dependent breakpoint is hit, it becomes disabled again until the master is hit next time. Hence you can form cascades of dependent breakpoints to satisfy any requirements. This feature works with all other conditions, filters, etc. |
Conditions
| Item | Breakpoint type | Description |
|---|---|---|
| Condition | All | 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 true or false), for example, str1.equals(str2). 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 true, user-selected actions are performed. If the result is false, the breakpoint does not produce any effect. If the Debugger cannot evaluate the expression, it displays the Condition evaluation error message. You can select whether you would like to stop at this breakpoint or ignore it. Conditions for field/method/exception breakpoints are calculated in the context for the given field/method/exception. |
| Instance filters | Line/ Method/ Field Watchpoint/ Exception | 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. |
| Class filters | Line/ Method/ Field Watchpoint/ Exception |
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 | Line/ Method/ Field Watchpoint/ Exception |
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 true, the breakpoint is hit. If it is false, no other actions are performed until the next breakpoint is reached. 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. |
Watch group
This options group is available for method breakpoints and field watchpoints only, and is required to specify under which circumstance the debugger should trigger the breakpoint.
Field watchpoints watch group
| Item | Description |
|---|---|
| Field access | Stands for triggering the breakpoint any time the field is accessed. |
| Field modification | Is selected when simple read attempts shouldn't cause the breakpoint to trigger. |
Method breakpoints watch group
| Item | Description |
|---|---|
| Method entry | Stands for triggering the breakpoint any time the method is entered. |
| Method exit | Stands for triggering the breakpoint any time the method is exited. |


and configure the filter
in the 