Try-With Resource when AutoCloseable is null

Question

How does the try-with feature work for AutoCloseable variables that have been declared null?

I assumed this would lead to a null pointer exception when it attempts to invoke close on the variable, but it runs no problem:

try (BufferedReader br = null){
    System.out.println("Test");
}
catch (IOException e){
    e.printStackTrace();
}

Latoya

Answer 1

The Java Language Specification specifies that it is closed only if non-null, in section 14.20.3. try-with-resources:

A resource is closed only if it initialized to a non-null value.

This can actually be useful, when a resource might present sometimes, and absent others.

For example, say you might or might not have a closeable proxy to some remote logging system.

try ( IRemoteLogger remoteLogger = getRemoteLoggerMaybe() ) {
    if ( null != remoteLogger ) {
       ...
    }
}

If the reference is non-null, the remote logger proxy is closed, as we expect. But if the reference is null, no attempt is made to call close() on it, no NullPointerException is thrown, and the code still works.

Tramp

Haha, the use-case you just added is what made me ask the question in the first place! Thanks! – Latoya

No way! That is wild. I just made it up. – Tramp

Well,. different variable types, but same structure :p – Latoya

Still cool! Nice to see the language designers thought of this case. – Tramp

I typically throw a caught exception if there is a problem where I would otherwise return null. It is a little much to have a catch block for every try-with-resources, but then having a null check is about the same. In fact, null check is actually a little slower (marginally) in optimal conditions, which is why I settled on throwing caught exceptions. – Raines

@Raines - My understanding is that an exception can be more expensive to throw than returning null. A null return value could be a normal case, or an exceptional case. My example is for the former. Exceptions are best used for the latter. – Tramp

Yes exceptions are more expensive to throw. But typically, in Java as opposed to languages like Python, exceptions aren't used for control flow and are used for problems. Catch blocks have no performance impacts in nominal cases. So the reason I like it is because in nominal cases it's cheaper. Again, we're talking marginal gains because it's an extra couple assembly statements under the hood for a null check, but my typical stance on computing is 'every little bit counts'. – Raines