Community
Participate
Working Groups
Build Identifier: It is possible for a breakpoint to be created and not registered, i.e. "hidden". e.g. hidden Java exception breakpoints are created to help debug uncaught runtime exceptions. In this case, the method IBreakpoint.isRegistered() will return false, indicating, for example, that the breakpoint should not be displayed in the Breakpoints view. The Markers view should check with isRegistered() method before deciding to display a breakpoint in the view. See screenshot. Reproducible: Always
Created attachment 186738 [details] screenshot showing markers view.
>Build Identifier: Please ;-) >Reproducible: Always Steps?
All you have to do to reproduce is launch a Java debug session and the two exception breakpoints will be added to your markers view. I've seen it in various versions of 3.6 and 3.6.2. Build id: M20110105-0951
There is no Platform concept of hidden markers. Debug should have requested the feature from the Platform. The history of this is, that before 3.4 there was no view that showed all markers and hence this wasn't an issue. Possible solution in Platform Debug (?): Pawel, Mike or Darin: is it necessary to create markers for hidden breakpoints? Possible solutions in Platform: - introduce the concept of hidden markers (IMarker.HIDDEN) - add an extension point that allows to contribute filters to the markers view I also created bug 334349: to flag those unregistered makers as non-USER_EDITABLE so that they can't be deleted from the Markers view for now. Moving to Debug for investigated whether we can solve it there.
(In reply to comment #4) > Possible solution in Platform Debug (?): Pawel, Mike or Darin: is it necessary > to create markers for hidden breakpoints? In its current state it is necessary to have a marker for a breakpoint. The reasons are may-fold, but mostly because: 1. all bp infos are stored / retrieved from the backing marker 2. we use resources / resource deltas in the bp manager for pretty much all of the bp monitoring > I also created bug 334349: to flag those unregistered makers as > non-USER_EDITABLE so that they can't be deleted from the Markers view for now. Along with that we should probably also update the JavaDebugOptionsManager to do the right thing in case someone does delete one of the hidden exception breakpoints. Currently we do nothing in breakpointsRemoved(), but we should probably handle the case that one of the hidden exception breakpoints is removed and update the state of the manager to reflect this.
(In reply to comment #4) > > Possible solutions in Platform: > - introduce the concept of hidden markers (IMarker.HIDDEN) > - add an extension point that allows to contribute filters to the markers view Either of these ideas would work, although the concept of hidden markers could serve other uses in the future. This implementation would have the lowest overhead. I also want to point out that it is not just hidden Java exception breakpoints that appear in the Markers view. Since any kind of breakpoint can be hidden, in the screenshot I attached, some hidden method breakpoints added by other plugins are also being displayed.
Moving this over the platform UI to see if they have any interest in either of the suggestions to filter markers: "Possible solutions in Platform: - introduce the concept of hidden markers (IMarker.HIDDEN) - add an extension point that allows to contribute filters to the markers view"
(In reply to comment #4) > Possible solution in Platform Debug (?): Pawel, Mike or Darin: is it necessary > to create markers for hidden breakpoints? IBreakpoint.getMarker() is allowed to return null so theoretically you should be able to get away with it. But, IMO if you remove the marker and you don't show the BP in the GUI, why would you bother creating the IBreakpoint object at all?
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.
