| Suspend | Select this check box to enable suspend policy for a breakpoint.
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.
| Suspend policy | Type of breakpoint | Description |
|---|
| All | Line/Exception/Field/Method | When a breakpoint is hit, all threads are suspended. | | Thread | Line/Exception/Field/Method | When the breakpoint is hit, the thread where the breakpoint is hit is suspended. | | Make default | Line/Exception/Field/Method | Click this button if you want the suspend policy specified for the breakpoint in question to be used as the default one for the subsequently created breakpoints. |
If the check box is not selected, no threads are suspended.
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.
- There are certain cases when IntelliJ IDEA will not stop at a breakpoint. Consider the following situation:
- Two breakpoints are set at the different methods of a class, and there suspend policy is set to All.
- When one of the breakpoints is hit, some step actions are performed.
- If at the time of stepping another thread hits the second breakpoint, profuct will not stop there.
|
| 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
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 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.
|
| Actions | In this section, select the check boxes to define the action to be performed on hitting a breakpoint:
| Action | Type of breakpoint | 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 | Line breakpoints | 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 expression <your_expression>.
| | Temporary | All types | A temporary breakpoint stops the program just once, and is then removed. |
|
| Watch | This options group is available for method breakpoints and field watchpoints only, and
is required to specify under which circumstance the debugger should trigger a breakpoint.
| Watch | Type of breakpoint | Description |
|---|
| Field access | Field watchpoints | Stands for triggering breakpoint every time the field is accessed. | | Field modification | Field watchpoints | This check box is selected when simple read attempts shouldn't cause the breakpoint
to trigger. | | Method entry | Method breakpoints | Stands for triggering breakpoint every time the method is entered. | | Method exit | Method breakpoints | Stands for triggering breakpoint every time the method is exited. |
|
| Filters | In this area, specify the filters to be used.
| Filter | Type of breakpoint | Description |
|---|
| 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. |
|
and configure the filter
in the 