Ergonomic Issues with ARM blocks

[Neal Gafter]

Here are some notes on ergonomic (usability) issues I found during my
attempt to retrofit some code with ARM blocks based on its latest
spec.

(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.  The problem is that it calls attention to the exceptional case
rather than the normal case, distracting the reader from the flow of
the business logic.  That is the very problem this construct should be
designed to solve.  This violates the principle that a language
construct should be designed to integrate well with the language as it
appears with the addition, rather than being designed to fit into the
language as it existed before the addition.  The try statement is
already the most complex statement form in Java; we should avoid
making it even more complex.  It would be better to use a new
context-sensitive keyword to define a new construct.  For example, one
might select the syntax

identifier (DeclSeq) Statement

Where the identifier would be semantically restricted to "using".
This form is unambiguous with the existing language.  I believe it can
be parsed without additional look-ahead by accepting a superset of the
grammar and post-filtering.  By selecting a syntax with no overlap to
existing forms, a context-sensitive keyword would not break backward
compatibility.  Java 7 will already be using context-sensitive
keyword(s) for the modularity extension, so the approach isn't novel.

(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).  Others have
raised the same concern this time around.  At the time, Josh's
position was "It was certainly my intention that the programmer not be
required to deal with exceptions thrown when terminating a
resource...".  That works out very nicely for some clients, and is a
killer for others.  The latest proposal abandons the set of use cases
well served by the previous specification, and attempts to serve the
set of use cases where exceptions on termination are best addressed by
the programmer.  From my (admittedly limited) experience, I found more
cases where it was appropriate to discard checked exceptions from
close() than otherwise.  A revision of the proposal addressing this
was promised.  The earlier solution was two distinct but related
statement forms.

(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.  Given the currently specified nesting,
the following code becomes more awkward when retrofitted with the ARM
construct:

LineNumberReader reader = getInput();
try {
  parseInput(reader);
} catch (CharacterCodingException ex) {
  report("character encoding error at line " + reader.getLineNumber());
} finally {
  try { reader.close(); } catch (IOException ex) {}
}

The proposal should not take a position on a "preferred" way of
combining/nesting resource usage with catch and finally.

This problem is easily solved by separating the new construct from
existing statement forms.  Then the programmer can mix or match the
separate language constructs as required for the application.

(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.

(5) Such ergonomic issues require significant time and experience to resolve

A language construct that affects so many distinct APIs with varying
patterns of use requires a significant body of experience to build
confidence that it is usable with them.  What little experience we
have with the present proposal suggests more work is needed.  In
addition, proposed (but not yet specified) solutions to the
retrofitting issue and promised solutions to other issues are novel
enough that they should not be adopted without a significant period of
time for experience with them to develop, and for the language
construct to evolve based on that experience.  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.