Community
Participate
Working Groups
build I20040318 Trying to track down some error handling problems, I made the following change to WorkbenchWindow.createDefaultContents: protected void createDefaultContents(final Shell shell) { if (true) { throw new Error(); } ... I then set a breakpoint on the first line (the if statement). The breakpoint was never hit. It went straight through to the throw.
We should likely warn of this at debug time. I.e. if the install of the breakpoint fails, it is similar to missing debug attributes.
Deferred
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 288083 has been marked as a duplicate of this bug. ***
*** Bug 352669 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > We should likely warn of this at debug time. I.e. if the install of the > breakpoint fails, it is similar to missing debug attributes. For hawk-eyed users, the problem becomes visible after the class has been loaded in the target: The bad breakpoints don't get a tick mark. Reopening as enhancement request for a more visible warning. Here's another test case: public static void main(String[] args) { for (int i= 0; i < 5; i++) { if (i < 3) { System.out.println(i); } else { break; // breakpoint will never be hit } } System.out.println("bye"); }
(In reply to comment #6) > (In reply to comment #1) > > We should likely warn of this at debug time. I.e. if the install of the > > breakpoint fails, it is similar to missing debug attributes. > > For hawk-eyed users, the problem becomes visible after the class has been > loaded in the target: The bad breakpoints don't get a tick mark. > > Reopening as enhancement request for a more visible warning. > I agree that we could use a bit of polish here, but I am not sure we could reliably tell the difference between the breakpoint not applying to a given type (because it has not been loaded, or belongs to a not yet loaded inner type) VS the given location being optimized out. We can tell the difference when the line infos are not available at all - we get an AbsentInformationException. Too bad there is not some way we could ask JDT core if a given location *would* be optimized out, then we could just add that to our toggle breakpoint adapter...
(In reply to comment #7) > Too bad there is not some way we could ask JDT core if a given location > *would* be optimized out, then we could just add that to our toggle > breakpoint adapter... There's no perfect solution, but if the class is already built (which it typically is), then you could use ToolFactory#createDefaultClassFileReader(..) to read the line number attributes from the generated .class file and thus identify lines that cannot serve as breakpoint targets.
I ran into this recently and wasted 10 minutes until I realized that my breakpoint was not hit due to this.
*** Bug 129339 has been marked as a duplicate of this bug. ***
