Ergonomic Issues with ARM blocks

[Florian Weimer]

* Neal Gafter:

> (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=dffxznxr_1nmsqkz&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=ddv8ts74_1d7tz65fd&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?