Community
Participate
Working Groups
3.7RC4 package pack; public class MyE extends Exception { /** * @param args */ public static void main(String[] args) { System.out.println("in top level MyE"); } } ------------------------------------------------------------- package pack; public class Bug { void foo() throws MyE { } } class MyE extends Exception { public static void main(String[] args) { System.out.println("in duplicate MyE"); } } In the above 2 CU's, note that MyE is a duplicate class. In one of the CU's I see a red cross and the problems view says "The type MyE is already defined". The editor however does not contain the error marker and just shows a warning marker. Hovering on the warning marker does show me both the error and the warning.
This is a regression from 3.6.2, where I see the correct error marker
(In reply to comment #1) > This is a regression from 3.6.2, where I see the correct error marker No it is not. This is broken since 3.1.
(In reply to comment #2) > [..] > No it is not. This is broken since 3.1. Did you try 3.6.2? It seems ok in 3.6.2 but broken in 3.6.1 or earlier
> Did you try 3.6.2? It seems ok in 3.6.2 but broken in 3.6.1 or earlier Do you really think I write "No it is not. This is broken since 3.1." below your statement that refers to 3.6.2 without trying it on 3.6.2?
This is a bug in JDT Core: the reconciler does not report the error.
Might be related to bug 160198.
(In reply to comment #4) > > Did you try 3.6.2? It seems ok in 3.6.2 but broken in 3.6.1 or earlier > > Do you really think I write "No it is not. This is broken since 3.1." below > your statement that refers to 3.6.2 without trying it on 3.6.2? Sorry. I could not see this bug in 3.6.2 in my workspace. But then I tried a fresh workspace and I could see the problem. Perhaps one of the settings cause the problem.
Jay, can you please investigate? Thanks!
(In reply to comment #0) > Hovering on the warning marker does show me both the error and the > warning. Dani, any clue how on hovering we get both the error and the warning? Does this mean the actual marker in the editor and the hover use different code?
Jay, I believe the problem is because of the fact that the error markers produced by the reconciler and the compiler are not the same here. The editor takes the markers from the reconciler (I think). In that respect, maybe fixing bug 342473 can also fix this problem. Just thinking aloud. :)
The same behavior can be observed even when we do a clean+build, where reconcile doesn't play any part.
(In reply to comment #11) > The same behavior can be observed even when we do a clean+build, where > reconcile doesn't play any part. Umm...the reconciler does come into action when we do a clean build, even if it should not. Thats what the bug 342437 is about no? Thats also why, when you do a clean build, you will see the error marker flicker for a minute and then disappear to give way to just the warning marker.
(In reply to comment #12) > Umm...the reconciler does come into action when we do a clean build, even if it > should not. Thats what the bug 342437 is about no? Thats also why, when you do > a clean build, you will see the error marker flicker for a minute and then > disappear to give way to just the warning marker. I didn't realize (until this you posted this) that you were talking about a bug different than Dani had pointed to (bug 160198). I will take a look at bug 342437.
> I will take a look at bug 342437. Bug 342437 seems unrelated to JDT. Typo? This bug here is simply about the reconciler not delivering the error while the builder does. At which point the reconciler is invoked (or not) is not part of this bug and should be discussed in other bugs if needed.
(In reply to comment #14) > Bug 342437 seems unrelated to JDT. Typo? Yes, it should read bug #342473
(In reply to comment #14) > This bug here is simply about the reconciler not delivering the error while the > builder does. At which point the reconciler is invoked (or not) is not part of > this bug and should be discussed in other bugs if needed. Pardon my ignorance. I was merely wondering how, when we hover over the marker on the editor, we see both the error and the warning, whereas the marker doesn't show that there is an error.
> Pardon my ignorance. I was merely wondering how, when we hover over the marker > on the editor, we see both the error and the warning, whereas the marker > doesn't show that there is an error. You mean when hovering in the ruler I guess (I don't see it when hovering over the editor text). There we show markers and annotations but the annotations from the editor (produced from problems reported by the reconciler) have higher priority as they are considered more recent than Java markers. We could say it's a bug that the error maker is shown at all in the ruler hover in this case.
(In reply to comment #17) > You mean when hovering in the ruler I guess (I don't see it when hovering over > the editor text). Yes, I meant the ruler. > priority as they are considered more recent than Java markers. We could say > it's a bug that the error maker is shown at all in the ruler hover in this > case. Ayush, isn't this the behavior you intended to report? We already have bug(s) for reconciler not reporting errors when only a single CU is compiled. So, this bug obviously need not address that.
(In reply to comment #18) > Ayush, isn't this the behavior you intended to report? We already have bug(s) > for reconciler not reporting errors when only a single CU is compiled. So, >this bug obviously need not address that. The solution should be to make sure that the reconciler DOES report the legit errors after a build operation is done. So, if there already are such bugs we can mark this is a dup. The other bug here, as Dani pointed out, is that the error marker from the compiler should not be shown in the ruler at all.
*** Bug 358553 has been marked as a duplicate of this bug. ***
Since Jay had to go on unavoidable unplanned time off for several days, this is not ready: retargetting to 3.8 M5.
I don't think I will have enough time for this release. Hence moving out of 3.8.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
