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