Community
Participate
Working Groups
According to the online help: "Breakpoints and exceptions can cause the thread to suspend before reaching the specified line." What really happens is that the "Run to Line" internal breakpoint is left enabled and at sometime later the program might stop at the "Run to Line" location. This is potentially confusing to the user since they will stop on a line that has no breakpoint icon and they would have to look at the status of the thread to determine why it stopped. More important, is that this behaviour is different from many other debuggers. The "Run to Line" action is considered an immediate request similar to a "Step over". If a "Step over" is interrupted by a breakpoint (in the called method) then the step over is cancelled. The user doesn't expect to stop at the original target location of the step over. In summary, Run to Line should be cancelled either when the program stops on the target location of the run to line or if the program stops for some other reason like a user breakpoint or exception as the help points out.
note that a preference now exists to "skip breakpoints for run to line". It is off by default for backwards compatibility. However, we could still update our run to line target to delete the run-to-line breakpoint when a non-run-to-line breakpoint is encountered.
On the topic of ignoring breakpoints on run to line, I have had a request to do the same for step over and step return. I was thinking about the "step filtering". It would be possible to add an entry in the list of things to filter... "Breakpoints"
Please enter a new feature reqest for skipping breakpoints while stepping (not likely to happen in 3.0).
*** Bug 51507 has been marked as a duplicate of this bug. ***
Deferred
open for 3.1
Fixed in RunToLineHandler and RunToLineAdapter.
please verify, Darin (S).
Verified and fixed that the AntLineBreakpoint created for the Ant run to line is not registered with the BreakpointManager so it correctly follows the Java debugger example. Changes to the Ant RunToLineAdapter.
I disagree that the Run-To-Line should be cancelled. I don't like any automatic/ hidden actions to occur when I am debugging. I believe that most of the time when run-to-line is executed but stops before it reaches that line, its because the user forgot to remove an old breakpoint. If you cancel the run- to-line breakpoint, you could force the user to start their whole debugging procedure over. I think the preferred method would be to have a "temporary breakpoint" icon. It should be removed when the debugging session is ended, or when the breakpoint is reached and subsequently passed, but not sooner. It can simply be a regular icon but it blinks. Again it will disappear when you leave the line, but not until it has been reached and stopped on at least once. Plus the option in preferrences. But for those who dont want this automatic skipping, it would be best to have a new icon.
I think of RuntoLine as a single action. If anything interrupts it, the action is complete. If the user really needs to get to a line then they should add a breakpoint. In fact I have used run to line knowing that it might stop at a breakpoint because I want the code to run but not go any further than the run to line location. If it hits the breakpoint then I start my work there. I don't want the program to later stop at the run to line location because I may not remember why it hit that line. Not sure I like the idea of a temporary breakpoint. There are already so many things being displayed in the ruler bar that they overlap and I can't tell what they are.
Perhaps my perspective is wrong, and I am actually thinking about "skip" to line. When you say "Run" to line, perhaps it is proper to stop at any existing breakpoints. However, we can't forget about the "to line." I don't think we should discard the notion of stopping at the line as commanded. Instead of having a special temporary breakpoint, we could have a status icon somewhere indicating that a RTL command is still active. It could blink or turn grey when the line is reached and the RTL command is completed. Also if you click on it you can cancel the active RTL command. I do like the notion of simply indicating to the user what is taking place, rather than discarding his command. Alternately we can add "skip (breakpoints) to line"
