Community
Participate
Working Groups
Created attachment 284084 [details] Visualization of issue When a generic *Exception* breakpoint mask is created, it may be impossible to bypass exceptions that occur when bringing Eclipse to the foreground, see the attached movie. I hoped to bypass this by explicitly setting a breakpoint on the unwanted throw and then disabling it. However, this does not work.
Did you try using trigger breakpoint for the exception breakpoint to disable other breakpoints?
(In reply to Sarika Sinha from comment #1) > Did you try using trigger breakpoint for the exception breakpoint to disable > other breakpoints? My aim is to find all places that throw exceptions. I want to trace down places were exceptions are swallowed. The OS method in question is visited multiple times. How does a trigger react when it is set in a method that gets visited multiple times, like in a listener.
Trigger point will not help the swallowed case but it can help for thrown cases.
(In reply to Sarika Sinha from comment #3) > Trigger point will not help the swallowed case but it can help for thrown > cases. Also when that throw point is visited many times?
Yes, you can control that by letting it be disabled or by re enabling the trigger breakpoint once it is hit.
(In reply to Sarika Sinha from comment #5) > Yes, you can control that by letting it be disabled or by re enabling the > trigger breakpoint once it is hit. It does not work. The *Exception* generic breakpoint overrules Trigger and Disabled breakpoints on that line.
(In reply to Wim Jongman from comment #6) > (In reply to Sarika Sinha from comment #5) > > Yes, you can control that by letting it be disabled or by re enabling the > > trigger breakpoint once it is hit. > > It does not work. The *Exception* generic breakpoint overrules Trigger and > Disabled breakpoints on that line. can you attach the video as to how it is overruling trigger point? which breakpoint was set as trigger point?
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.
