This change is easy to explain, but it has proved to have hidden subtleties, which
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.

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")) ) {
...
}

Let’s assume that the file (someFile.bin) exists, but it might not be an ObjectInput
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:

读书笔记：The Well-Grounded Java Develope