made it much less easy to implement than originally hoped. The basic idea is to allow
a resource (for example, a file or something a bit like one) to be scoped to a block in
such a way that the resource is automatically closed when control exits the block.
This is an important change, for the simple reason that virtually no one gets manual resource closing 100 percent right. Until recently, even the reference how-tos from Sun were wrong. The proposal submitted to Project Coin for this change
includes the astounding claim that two-thirds of the uses of close() in the JDK had
bugs in them!
Fortunately, compilers can be made to produce exactly the sort of pedantic, boilerplate code that humans so often get wrong, and that’s the approach taken by this change.
This is a big help in writing error-free code. To see just how helpful, consider how
you’d write a block of code that reads from a stream coming from a URL (url) and
writes to a file (out) with Java 6. Here’s one possible solution.
Murphy’s Law applies—anything can go wrong at any time:
■ The InputStream can fail to open from the URL, to read from it, or to close
properly.
■ The File corresponding to the OutputStream can fail to open, to write to it, or
to close properly.
■ A problem can arise from some combination of more than one factor.
This last possibility is where a lot of the headaches come from—a combination of
exceptions is very difficult to deal with well.
This is the main reason for preferring the new syntax—it’s much less error-prone.
The compiler isn’t susceptible to the mistakes that every developer will make when trying to write this type of code manually.
Let’s look at the Java 7 code for performing the same task as listing 1.3. As before, url
is a URL object that points at the entity you want to download, and file is a File object
where you want to save what you’re downloading. Here’s what this looks like in Java 7.
try (OutputStream out = new FileOutputStream(file); InputStream is = url.openStream() ) { byte[] buf = new byte[4096]; int len; while ((len = is.read(buf)) > 0) { out.write(buf, 0, len); } }
This basic form shows the new syntax for a block with automatic management—the
try with the resource in round brackets. For C# programmers, this is probably a bit
reminiscent of a using clause, and that’s a good conceptual starting point when working with this new feature. The resources are used by the block, and they’re automatically disposed of when you’re done with them.
You still have to be careful with try-with-resources, as there are cases where a
resource might still not be closed. For example, the following code would not close its
FileInputStream properly if there was an error creating the ObjectInputStream
from the file (someFile.bin).
try ( ObjectInputStream in = new ObjectInputStream(new FileInputStream("someFile.bin")) ) { ... }
file, so the file might not open correctly. Therefore, the ObjectInputStream wouldn’t
be constructed and the FileInputStream wouldn’t be closed!
The correct way to ensure that try-with-resources always works for you is to split the
resources into separate variables.
try ( FileInputStream fin = new FileInputStream("someFile.bin"); ObjectInputStream in = new ObjectInputStream(fin) ) { ... }
One other aspect of TWR is the appearance of enhanced stack traces and suppressed
exceptions. Prior to Java 7, exception information could be swallowed when handling
resources. This possibility also exists with TWR, so the stack traces have been enhanced
to allow you to see the type information of exceptions that would otherwise be lost.
For example, consider this snippet, in which a null InputStream is returned from
a method:
try(InputStream i = getNullStream()) { i.available(); }
This will give rise to an enhanced stack trace, in which the suppressed NullPointerException (NPE for short) can be seen:
at wgjd.ch01.ScratchSuprExcep.run(ScratchSuprExcep.java:23)
at wgjd.ch01.ScratchSuprExcep.main(ScratchSuprExcep.java:39)
Suppressed: java.lang.NullPointerException
at wgjd.ch01.ScratchSuprExcep.run(ScratchSuprExcep.java:24)
1 more
We encourage you to use try-with-resources as soon as you’re able, to eliminate unnecessary bugs from your codebase.
TWR and AutoCloseable
Under the hood, the TWR feature is achieved by the introduction of a new interface,
called AutoCloseable, which a class must implement in order to be able to appear
as a resource in the new TWR try clause. Many of the Java 7 platform classes have
been converted to implement AutoCloseable (and it has been made a superinterface of Closeable), but you should be aware that not every aspect of the platform
has yet adopted this new technology. It’s included as part of JDBC 4.1, though.
For your own code, you should definitely use TWR whenever you need to work with
resources. It will help you avoid bugs in your exception handling.