Proposal: Automatic Resource Management (original) (raw)

Neal Gafter neal at gafter.com
Sat Feb 28 07:41:11 PST 2009

Josh-

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

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. Particularly concerning to me is the fact that this translation would sometimes silently swallow exceptions indicating serious program failures (this too should be listed among the disadvantages); completing the exception analysis specification would make that problem more obvious. What are the completion analysis rules? If the variable becomes null before the finally block, is NullPointerException thrown? What if the variable is assigned to some other value? Does this construct then close some other resource than the one opened? 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. The fact that you proposed two possible but semantically distinct translations suggests that not all is settled.

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.

More information about the coin-dev mailing list