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.

How close did you get? The key point here is that when handling external resources,

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

...

}

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:

Exception in thread "main" java.lang.NullPointerException

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.

读书笔记：The
Well-Grounded Java Develope