Breakpoints are instructions which interrupt program execution at specific source lines so you can monitor the program state at the point of suspension. They can be created in module code such as triggers and user-named PL/SQL program units, packages, and libraries.
You can set breakpoints on any source line that is executable, that is, source lines that contain one or more statements for which code is generated when you compile the program. For example, assignment statements and procedure or function calls are executable, while comments, blank lines, or some declarations are not executable.
When you run your module containing breakpoints in debug mode, execution is suspended just before reaching the source line on which a breakpoint is set. Control is passed to the debugger, and at this point, you can incrementally execute the rest of the program, and inspect the program state or modify variable values along the way. You can temporarily disable specific breakpoints and then re-enable them later if necessary.
Consider the following code where a breakpoint is set on line 5.
When this code is run in debug mode, suspension occurs after line 4 is executed. The local variable TOTAL_WAGES is 0 while COUNTER is still NULL because suspension occurred just before line 5 (where the breakpoint is set).
You can set breakpoints before you run the module and while the module is running or suspended. Breakpoints set during a Builder session are not lost when you stop debugging (without exiting the Builder). However, they are not saved when you terminate the Builder session.
When using the debugger across different machines to debug FMX and FMB files, the target files that are to be debugged must be regenerated on the target machine if you move them.
For example, if you have an FMB and an FMX that are generated on machine A, and you copy them over to machine B, and if your client debugger is on machine C, any breakpoints that you set on the files on machine B will be ignored by the debugger. You will need to regenerate the files on machine B in order for the client debugger on machine C to see the breakpoints.
About the Current Execution Location and Current Stack Frame