Breakpoints in the JavaScript Debugger
 |
The JavaScript Debugger (beta) is currently available in preview mode only and is not a verified feature in ThingWorx Platform 10.0.x releases.
|
Breakpoints define locations within the code where the script execution pauses for inspection. For more information about debugging code in ThingWorx, see JavaScript Debugger. Breakpoints help you check the values of variables in code for accuracy.
Breakpoints can be set or changed in read-only, edit, or debug modes. Breakpoints are saved in the system and remembered for the current user. Each user maintains their own set of breakpoints.
You can add, remove, or edit breakpoints in the gutter area to the left of the numbered column in the script editor. You can click the gutter area next to a line of code to add a breakpoint as long as the code is not a comment or a blank line. If you click an existing breakpoint, it will be removed.
You can right-click in the gutter area next to a line of code to modify the behavior of breakpoints using the following options:
• Add breakpoint— Allows you to add a breakpoint. A blue circle indicates a breakpoint in the code. If the line of code already has a breakpoint, is empty, or has a comment, the Add breakpoint option is hidden.
• Edit breakpoint— Allows you to add a conditional statement to the breakpoint. The debugger pauses at the breakpoint only if the condition is met. A conditional breakpoint is indicated with an orange circle. To edit a breakpoint, perform the following steps:
1. Right-click an existing breakpoint.
2. From the list that appears, select Edit breakpoint.
3. In the Conditional Breakpoint field, and enter the conditional statement.
4. Press the Enter key, or click 
to enable the conditional breakpoint.
to enable the conditional breakpoint.If you press the Esc key or click outside of the Conditional Breakpoint field, your changes will not be saved.
• Disable breakpoint— Allows you to disable a breakpoint. When disabled, the breakpoint is saved but the debugger does not pause at the line. A disabled breakpoint appears transparent or has an orange circle with a gray border.
• Enable breakpoint— Allows you to activate a disabled breakpoint. This option is available if a breakpoint is currently disabled.
• Remove breakpoint— Allows you to remove an existing breakpoint.
• Remove All Source breakpoints— Allows you to remove all breakpoints defined for the current code.
Remove All breakpoints— Allows you to remove all existing breakpoints in the system.
• Deactivate breakpoints— Allows you to deactivate all breakpoints so that they are ignored during debugging. A deactivated breakpoint has a circle with a gray slash through it.
• Activate breakpoints— Allows you to set all breakpoints as active.
Breakpoint Limitations and Debugging Considerations
In some cases, a breakpoint may not pause execution even though the UI allows you to set it. This occurs when the breakpoint is placed on code that is not executed at runtime.
A breakpoint may not stop execution due to the following:
• Non-Executable Code—Breakpoints can only pause execution on lines that contain executable statements. Breakpoints will not trigger on:
◦ Empty lines
◦ Comments
◦ Variable declarations without assignments
◦ Structural keywords without executable content
◦ Certain complex expressions that span multiple lines (the debugger may not detect the correct execution point)
• Sophisticated or Undetected Logic—Although the UI prevents placing breakpoints on clearly non-executable lines (for example, blank or commented lines), more complex cases are not always detected. As a result, the UI may allow setting a breakpoint on a line that never actually executes.
If a breakpoint does not pause execution:
• Move the breakpoint to another nearby line that contains a clear, standalone executable statement.
• If needed, refactor complex or chained expressions into multiple simpler lines to create valid breakpoint locations.