Ergonomic Issues with ARM blocks (original) (raw)

Florian Weimer fw at deneb.enyo.de
Sun Mar 29 11:37:11 PDT 2009

(1) "try" is not a natural keyword for the intended semantics.

The use of the try keyword for this construct is natural while migrating existing code, because the existing solution already requires a try-finally statement. But it is a non sequitur (in some cases shockingly inappropriate) when reading code or when writing new code.

I'm also not convinced that a construct which adds another indentation level is desirable. It adds quite a bit of syntactic clutter, and I think the clutter is one of the reasons why we see too little use of explicit resource management.

(2) Checked exceptions from close() should be discarded for some clients.

Experience with the previous prototype <http://markmahieu.blogspot.com/2008/01/exception-handling-with-arm-blocks.html> of the previous (now 3-year-old) ARM proposal <http://docs.google.com/View?docid=dffxznxr1nmsqkz&pli=1> raised issues of handling exceptions from closing resources (some APIs wanted exceptions from close() discarded, others did not).

I think this is related to the lack of an initializer in the old proposal. If you need to specify an initializer to use the construct, it's very likely that the initializer will throw, too (at least for IOException).

(3) The nesting of new behavior with old behavior in the try statement is a poor fit for many clients.

Another issue arises due to the nesting of new behavior with existing behavior in the try statement. By retrofitting the construct onto an existing statement form, the language has made a decision on the relative nesting of the two behaviors. Is the resource variable in scope in the catch block? Is it in scope in the finally block? Any particular answer to these questions is a good match for some clients and a poor match for others.

I agree that these are strong arguments against an approach based on "try".

(4) The proposed construct doesn't retrofit onto many APIs in the profile of use-cases for which it was designed.

A separate conversation regarding an analysis of the use cases was moved off-list, ultimately identifying widely used APIs that ought to be retrofittable with this construct. See <http://docs.google.com/View?docid=ddv8ts741d7tz65fd&pageview=1&hgd=1&hl=en>. One result of that analysis was that the proposal is incompatible with a number of widely used types that ought to be retrofitted. A revision of the proposal addressing this was promised.

There are still a few ones missing from that document (java.lang.Process, for instance). And there are some cases where the lack of an explicit release is rather close to an API bug (roughly anything which acquires native resources, I guess), which was not deemed worth fixing because explicit resource management cannot reasonably be forced on users. In other words, I expect that there will be many more users of this functionality once it is available in the language, more than what is suggested by current APIs.

We would do a disservice to Java programmers by shoving an untried solution in a rush through a process designed to handle small, simple, noncontroversial changes.

Is there are chance to move this into some channel which can deal with more long-term, significant language changes, but is as accessible as COIN?

More information about the coin-dev mailing list