Community
Participate
Working Groups
Using HEAD, if the contents of a unit cannot be retrieved because of a java.io.CharConversionException, the compiler is failing silently. No class file is produced and no error is reported to the user. The problem comes from the getContents() in org.eclipse.jdt.internal.compiler.batch.CompilationUnit. The try/catch IOException is eating any IOException and then returns an empty array. This leads to no error from the compiler and no class file produced.
Created attachment 35936 [details] Patch for surfacing the failure as a problem
Created attachment 35938 [details] Better patch
Added 2 new problem IDs: /** @since 3.2 */ int InvalidEncoding = Internal + 701; /** @since 3.2 */ int CannotReadSource = Internal + 702; Mike - same non breaking API changes for problems which weren't surfaced ever. This has been critical to some users of invalid files, for which compilation just stops in the middle, as exception was swallowed, and treated as if empty file instead ?! Now we will produce a compile error. ---------- 1. ERROR in d:\HelloWorld.java !! no source information available !! Cannot read the source from d:\HelloWorld.java; either the file uses a different encoding than utf8 or it is corrupted ----------
Fixed by wrappering the IOException in AbortCompilationUnit (unchecked), and checking for it later on during early parsing stage. Released to HEAD. Will issue v_645a with this change.
Was there no exisitng constant that is generic enough to handle this? Should we add a "generic error" constant to deal with problems that are found after the API freeze (which could be replaced with better ones later)? I'm ok with this change because it is non-breaking, but it's time to get out of this mode. Essentially, we need to start believing that fixing a bug is not a valid reason to add API, unless the bug is P1.
Compiler bugs are often critical; especially this one is. If there is any problem ID we can reuse, we would generally shoot for it, but if not like here, then we have to add an ID. New problems are never causing any grief to any client. The only ones who would care are quickfix providers, which would simply not assist on new problem IDs (like JDTUI for instance. The coverage isn't super high on these)
Verified for 3.2 M6 using build I20060328-0010
Note that there is no regression test for this problem since on Windows encoding problems are not reported. Thus this test would be Linux specific . It means that a developer running on Windows only would not see that s/he broke the test. This could cause integration builds failures.
