Java试用资源辩论

Question

Ok now, at my job we're having a debate over try-with-resources and exception suppression.

Quick recap: try-with-resources, from java 7, eliminates the need for that pesky finally block to close resources. I personally feel it is way more elegant, but I have a coworker who isn't convinced. He doesn't like that the one exception gets suppressed, and has been arguing that we loose information through that.

At first I was taking his word for it, because I'm a junior dev and he's senior, I'm new, etc. But I recently discovered that hey, all the info makes it into the stack trace, including the suppressed exception. So no information is lost there.

The last piece of this debate that I'm looking for (since I'm advocating for try-with-resources) is how auto-closeable handles that exception. Let's say an exception is thrown while trying to close a resource, is there the potential that resource could stay open and leak? Ultimately this may not be such a big deal, since the logs would alert us to this issue anyway.

Just curious. Thanks so much.

Answer 1

You are correct that suppressing the exception does not result in losing information. Your co-worker's concern about that is groundless. The points of try-with-resources are:

• to make sure that resources get closed, regardless of what is thrown while using them, and in the reverse order in which they're declared,

• to make sure that exceptions thrown on close don't cause exceptions thrown in the try block to get lost, and

• to make sure that exceptions thrown on close still get retained as suppressed exceptions so no information is lost.

If closing a resource throws an exception, there's nothing you can do about it in either case. In JDBC the database objects communicate back to the database server to tell it to de-allocate resources, and those would stay open if close fails. (And retrying is usually pointless anyway because the problem is typically that something changed about the network or the connection.) But the server will clean those up eventually, and it's out of the client code's hands. Both try-with-resources and the older try-finally idiom do an equally good job of closing resources, it's just more work and more typing with the try-finally idiom.

The biggest difference to me in whether to use try-with-resources or nested try-finally statements is that in the former case, if nothing is thrown in the try block and something is thrown on close, the exception thrown on close is thrown (since there's no exception thrown in the try-block to attach it to as a suppressed exception). If you use nested try-finally blocks then you can make sure exceptions thrown on close do not propagate from the finally block, so that an intermittent network glitch while releasing resources doesn't result in losing a valid business transaction.

But in practice very few people have the tolerance for this kind of nesting and they take shortcuts that lead to resource leaks (typically connections that don't get closed because an earlier call in the finally block failed). People also tend to write code that causes exception-masking (mentioned in the second bullet point), where the exception thrown on close causes an exception thrown within the try-block to be lost; try-with-resources prevents this kind of error. There is definitely a place for try-with-resources.

My advice is to learn all you can about exception handling, write example programs demonstrating how exceptions work, and understand the strong and weak points of both approaches so that you can talk about them in detail and compare and contrast. That way you can show that you understand the concerns your co-workers raise and you can give advice not as an advocate for one way over the other but with a goal of helping your group find solutions that help it write better software.