RFR: 8216400: improve handling of IOExceptions in JavaCompiler.close()
Jonathan Gibbons
jjg at openjdk.java.net
Fri Dec 25 23:45:55 UTC 2020
On Fri, 25 Dec 2020 16:22:22 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:
> Hi all,
>
> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
>
> Thank you for taking the time to reivew.
>
> Best Regards.
Changes requested by jjg (Reviewer).
src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1825:
> 1823: JCDiagnostic msg = diagFactory.fragment(Fragments.FatalErrCantClose);
> 1824: throw new FatalError(msg, e);
> 1825: }
The comment is meant to suggest the following:
`
FatalError fe = null;
for (Closable c : closeables) {
try {
c.close();
} catch (IOException e) {
if (fe == null) {
JCDiagnostic msg = diagFactory.fragment(Fragments.FatalErrCantClose);
fe = new FatalError(msg, e):
} else {
fe.addSuppressed(e);
}
}
}
if (fe != null) {
throw fe;
}
`
(Apologies if there are any errors in that: I just typed it in directly.)
This is probably a case where you could probably get away with no test and use the label `norge-hard`. If you were to write a test, it would have to involve creating multiple file system artifacts that cannot be closed, perhaps by creating wrappers that always throw exceptions when `close()` is called.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1895
More information about the compiler-dev
mailing list