Proposal: Automatic Resource Management (original) (raw)

Joshua Bloch jjb at google.com
Sat Feb 28 11:08:04 PST 2009

Neal,

On Sat, Feb 28, 2009 at 7:41 AM, Neal Gafter <neal at gafter.com> wrote:

Josh-

The compatibility section must document incompatibilities, whether or not you judge them likely to cause problems in practice.

Good point. I will add this one. And I am still interested in whether anyone can find some code in an existing codebase that tickles this.

To be complete at a level suitable for project coin, you should provide a specification of all of the semantics. For example, there is nothing comparable to JLS section 11.2.2, exception analysis, which for this construct is much more complex than the existing statements and therefore must be spelled out.

I have done so in the "Semantics and Compilation" section: it's implicit in the desugaring. The project lead (Joe Darcy) said this in a personal communication: "I suppose the desugarings should cover issues related to flow analysis with the new statement form." Of course we can translate the desugaring into JLS-ready prose when the time comes, but I don't think it would aid in understanding the proposal.

Particularly concerning to me is

the fact that this translation would sometimes silently swallow exceptions indicating serious program failures

Unless I am missing something, the construct only "silently swallows" exceptions when they are intentionally suppressed in favor of prior exceptions, which typically indicate more serious problems. I did describe, in the "Additional Features" section, a facility whereby suppressed exceptions are associated with the exception for which they were suppressed:

Here are several features that might be added to the construct if the expert group deemed it advisable:

Retaining suppressed exceptions - As described above, the construct simply discards exceptions that are suppressed. It would probably be better to attach them to the exception in whose favor they are being suppressed. This would entail adding two new methods to Throwable, void addSuppressedException(Throwable) and Throwable[] getSuppressedExceptions().

I do think this is worth doing, and I will "promote it" to the body of the proposal if that is the consensus.

If the variable becomes null before the

finally block, is NullPointerException thrown?

As per the desugaring, the resource variable is implicitly final. In any practical use, you'll get an NPE in the explicit block, but yes, if you construct an artificial example where the resource is not actually used, you'll get a NullPointerException in the (implicit) close, again as per the desugaring.

What if the variable is assigned to some other value?

It won't compile, as the variable is implicitly final. My guess is that you had a hard time reading the desugaring due to the lack of formatting. I'll send you the pdf:)

Does this construct then close some other resource than the one opened?

Sorry, but I don't understand this question. Again, I suspect the desugaring will make this clear.

These questions should be clear from the spec, and for these questions the answer is either unclear or quite unlikely to be what you intend.

I don't think this is true. In each case you've mentioned, the behavior was intentional and is clearly specified by the desugaring. I believe that it would be straightforward to translate the desugaring into JLS-style prose, but I don't think it would improve the proposal. As the proposal says, my intent was to "emphasizes brevity and clarity."

The fact that you proposed two possible but semantically distinct translations suggests that not all is settled.

Sorry for the confusion. I did this for pedagogical reasons. The first translation was meant to quickly explain the construct. The second was meant to add a desirable feature, and should be regarded as correct. I could remove the first one from the proposal and go straight to the second, but I'm afraid the resulting proposal would be harder to understand. I will add prose to clarify that the second desugaring supersedes the first.

In the C# world, the using statement has the "shoehorning" issue that I described. I can tell you from experience that it does encourage clients to implement the IDisposable interface, and a method named Dispose, to use the pattern, even though that may be very unnatural to the API. It is a flaw in the language that we're aware of and working to repair.

I have little experience with C# so I'll have to defer to you on issues concerning this language. But in Python, I am led to understand that the with statement is very well liked. The same goes for the the RAII pattern in C++. The need for automatic resource management in Java is made abundantly clear by the fact that 2/3 of the uses of the close method in the JDK are wrong. I myself got it wrong (twice) in java.util.prefs. And our solution on page 88 of Java Puzzlers is also wrong: it silently swallows the exception when closing a file that was open for write.

       Josh

More information about the coin-dev mailing list