Bugzilla – Full Text Bug Listing
| Summary: | Incremental builder stops showing squiggles | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, jarthana, stephan.herrmann |
| Version: | 4.13 | ||
| Target Milestone: | 4.14 M3 | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=486979 https://bugs.eclipse.org/bugs/show_bug.cgi?id=534906 https://git.eclipse.org/r/152686 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=62050b74fac53d50e60a594ecb3a5be6d7ba9a70 |
||
| Whiteboard: | |||
|
Description
Ed Willink
Please provide steps to reproduce the problem or a test project. Surely the stack trace shows the exception propagating through a loop that should catch it? The location where IncrementalImageBuilder.writeClassFileCheck() calls Util.getResourceContentsAsByteArray() already catches ClassFormatException for a corrupt .class file. I think treating a missing .class file in the same way is OK and IMHO doesn't need a test (rare exception :) ). From Eclipse p.o.v. the .class file should of course never disappear under foot, but idiots like a stray "mvn clean" still shouldn't cause more trouble than necessary. The build result may still be corrupt, when unexpectedly .class files are missing ... so avoiding the exception will give no guarantee that things are fine. (In reply to Stephan Herrmann from comment #3) > From Eclipse p.o.v. the .class file should of course never disappear under The class file is in an auto-generated project for which re-auto-generation deletes all contents, so the bin file will be deleted. From similar problems in a variety of applications the generic problem that I recognise is that given: loop-over-many-artefacts do-something-with-the-artefact if the (loop-iterator or an) individual do-something fails the rest of the loop fails. Therefore the worker loop needs to be coded as loop try get-next-artefact do-something-with-the-artefact catch maybe-log-problem to ensure that the worker loop only fails for the bad artefact, rather than everything thereafter. A superficial inspection of the stack trace suggests a builder nominally building many things that fails on one and so fails for all thereafter. However the problem is worse since even after closing the offending project, JDT incremental update remains inactive. So perhaps the broken/absent class file remains somewhere within Eclipse and continues to cause grief. Unexpected files/projects were identified as causing problems for the Type Hierarchy. See Bug 486979 where a specific fix was provided, with Bug 534906 opened for the general fix. I suspect this is a variant instance of the same underlying problem with bad files. Perhaps the recent Bug 486979 fix created this as a new problem. New Gerrit change created: https://git.eclipse.org/r/152686 Gerrit change https://git.eclipse.org/r/152686 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=62050b74fac53d50e60a594ecb3a5be6d7ba9a70 (In reply to Eclipse Genie from comment #6) > Gerrit change https://git.eclipse.org/r/152686 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=62050b74fac53d50e60a594ecb3a5be6d7ba9a70 This should catch the exception from comment 0. Released for 4.14 M3 Verified for 4.14 M3 using code inspection. |