简体   繁体   中英

Is the close method on a try-with-resources idiom not called if a constructor throws an exception?

I have a base class Base and a child class Child which extends it. Base implements java.lang.AutoCloseable .

Let's suppose that the constructor for Child throws a Foo .

Now consider

try (Base c = new Child()){
    /*Some code*/
} catch (final Foo e){
    /*Some more code*/
}

Is the Base#close method called if the exception is thrown? It is not on my machine, but is this something that the JLS has standardised?

Yes, close won't be called. This is specified in the JLS section 14.20.3 :

Resources are initialized in left-to-right order. If a resource fails to initialize (that is, its initializer expression throws an exception), then all resources initialized so far by the try-with-resources statement are closed . If all resources initialize successfully, the try block executes as normal and then all non-null resources of the try-with-resources statement are closed.

Resources are closed in the reverse order from that in which they were initialized. A resource is closed only if it initialized to a non-null value . An exception from the closing of one resource does not prevent the closing of other resources. Such an exception is suppressed if an exception was thrown previously by an initializer, the try block, or the closing of a resource.

In this case, an exception is thrown in the constructor so the resource is not initialized to a non-null value. Hence, the close method isn't called.

close will not be called. It wouldn't make sense to call it, since you don't have a fully-constructed object to close, and in similar calls, you might not have even entered a constructor:

try (Base b = makeBase()) {
    ...
}

where makeBase is

Base makeBase() {
    throw new RuntimeException();
}

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM