Community
Participate
Working Groups
Exception breakpoint can be scoped on throwing class or package. However, it be very handy to be able to scope on calling method, class or package. That is, don't break on this exception, unless this method (class or package) is on the call stack.
deferred for post 2.1
*** Bug 69249 has been marked as a duplicate of this bug. ***
Another request for this feature (e-mail): "I slowly come to the conclusion that quick fixing an exception isn't that easy <g> However, you could help me more when an exception is thrown. For example, when there is a NullPointerException, I want to rerun with the NullPointerException caught. However, I'd like to rerun with the exception filtered to the failure location (otherwise I stop at many useless locations). Now the problem is that I have to enter the filter expression and this is painfull since you have all the information (in addition not many users will find the filter page, but we have discussed this is in the phone call already, it would also be good to make the properties dialog available when I create the exception breakpoint)."
*** Bug 67703 has been marked as a duplicate of this bug. ***
Also see bug 72961
*** Bug 75417 has been marked as a duplicate of this bug. ***
We are looking at ways to generalize this support to all breakpoints -i.e. scope breakpoints based on the execution path in which they are encountered.
Some ideas for the new "execution path breakpoint" feature: - It should be possible to create this filter condition or a breakpoint with this filter condition during a debug session while stepping after reaching a breakpoint. - Multiple paths seem reasonable to me. - Path length should be controllable, i.e., the number of stack frames to examine (that's probably also performance relevant).
NOTE: scoping is applicable to all breakpoints - not just exception breakpoints.
*** Bug 36804 has been marked as a duplicate of this bug. ***
not planned for M4
Deferred
*** Bug 134513 has been marked as a duplicate of this bug. ***
The suggested workaround to 145190 implies a solution to this bug. An add-this-location-as-breakpoint-filter context menu entry in the Debug stack trace would be good.
reopening
The refusal to fix 145190 makes this a real pain. Every time I switch between outer and inner Eclipse sessions while debugging a text editor I risk getting: Thread [main] (Suspended (exception IllegalArgumentException)) SWT.error(int, Throwable, String) line: 3547 SWT.error(int, Throwable) line: 3481 SWT.error(int) line: 3452 StyledText.getOffsetAtLocation(Point) line: 3793 just because the cursor happens to be in noman's land. I need to be able to filter out the broken StyledText location without filtering all SWT errors or ignoring all IAEs.
