Community
Participate
Working Groups
If a user accidentally toggles the skip all breakpoints in the Breakpoint View toolbar, the user is in deep trouble and left puzzled as to why Eclipse debugging is broken. It would appear that some JDT cache has crashed. a) The breakpoint decorator blob has a line through it; good. But the hover text / associated actions give no clue as to why. There should at least be - text to say that all breakpoints are skipped - text/action to guide in unskipping b) there should be a Window Preferences checkbox that allows the skipping setting to be unset c) The Breakpoints View should have menu actions corresponding to the toggle icon d) If a user defines a new breakpoint while they are skipped, a popup should warn of the skipping, until the don't tell me again preference has been set - resettable from Windows preferences. e) The breakpoints view should have some banner / shading / hovertext to warn that the debugger utility has been crippled. f) starting a debug session with all breakpoints skipped should present a pop-up warning of the hazard.
This seems to be a seriously misconceived functionality. Trying to imagine how it might be used, I see three use cases. a) run-to-completion After sufficient debugging, the user may have no further need of breaks and so may just wish to run to completion to see how any tweaked state works out. This one-shot action would be much better served by a one-shot action such as a Run-to-completion button, rather than a sticky functionality that gets stuck in a stupid position. b) no-debugging If the user has no need of debugging they may disable all breakpoints, but surely in this case they would use a Run rather than Debug activation? The ability to convert Run to Debug seems of very little use and given the ability of the sticky setting to cripple the debugger, it is clearly dangerous. c) Run vs Debug inconsistency Some confusing often GC-related issues can manifest as a fail when Run, but success under Debug. In this case a more-or-less Run-like Debug may be appropriate. But given the rarity of this use case, surely setting a breakpoint in 'main()' where a one-shot skip all may take control. Perhaps breakpoints may be resumed after a manual pause. None of these use cases seem to justify the skip all breakpoints being active at the start of a debug session. Any persistence of the setting should vanish when debug starts. And no need to refresh editor displays when a standalone non-debug launch occurs.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Cannot be stale until triaged by a relevant committer.
