Using Breakpoints in the Debugger
Breakpoints interrupt execution of your code. The debugger stops before executing a line of code that contains a breakpoint.
Include breakpoints at important points in your code so that you can observe the flow of code or determine the values of variables at a specific point in your code.
Breakpoints are invalid for blank lines, lines that contain only comments, and end instruction lines.
You can set breakpoints from the Debugger window or from the JADE development environment.
For details about enabling or disabling breakpoints, see "Using Conditional Breakpoints and Pass Counts", later in this chapter.
You can set breakpoints in any JADE method.
After re-compiling a method while using the JADE debugger, the debugger continues to display the old method source under the following circumstances.
-
The application is displaying a modal form.
-
The debugger next stops on a breakpoint in the same method that was compiled and that method was the last displayed by the debugger.
When the debugger is at a breakpoint:
-
If nothing is selected and you hover the mouse over a variable, the value of the variable is displayed when possible (including path expressions). No methods are executed.
-
If an expression is selected, hovering over the selection attempts to execute the expression. The expression must be compilable within the context of the method and must return a value.
If the compile and execution succeed, the returned value is displayed.
It is your responsibility for the effects that the expression may have on the database and execution of the method logic.
When the application has stopped on a breakpoint and the Continue action is performed, the debugger clears the debugger displays, including the last method shown when the execution stack becomes empty.
If a modal form is displayed, the execution stack does not become empty and the debugger displays are not cleared.
If the next breakpoint encountered is in the same method, the debugger retains the currently displayed method.
When the application becomes idle and a modal form is displayed, the debugger clears the debugger displays and the new method source is displayed when a breakpoint is next encountered in that method.
If the method is changed and re‑compiled while the debugger has stopped on a breakpoint in that method (or in another method while that method is on the call stack), the interpreter will not reload that method logic until all copies of the method execution have exited from that method.
The debugger continues to display the old source while breakpoints are only encountered in that method until the application execution again becomes idle.
After a breakpoint is encountered in any other method, any breakpoint subsequently encountered in the changed method displays the new source, regardless of whether the old or new version of the method is being executed.
For more details, see the following subsections.
