PROPOSAL: open and close brace optional for single statement try, catch, finally, method declaration

[Glenn A. Marshall]

1.  This example is syntactically invalid since the first try does not have
a catch nor finally clause; it is not ambiguous.  Good example tho.

The existing scoping of a catch, finally in the same scope corresponding to
the immediately preceding try is not affected by this proposal.

The existing requirement that a try be immediately followed by its catch,
finally is not affected by this proposal.

2.  The optional omission of the braces is only applicable to simple, single
statement try, catch, finally (and method declaration).  Braces are still
allowed, and are required for disambiguation, as well as for multiple
statement try, catch finally (and method declaration).  They are are needed
in this example.

On Sun, Mar 29, 2009 at 10:27 PM, Neal Gafter <neal at gafter.com> wrote:

> The proposed syntax is ambiguous.  If one writes
>
> try
> try stmt;
> catch(...) stmt;
> catch(...) stmt;
> finally stmt;
>
> To which try statement is the second catch block attached?  Please provide
> an unambiguous syntactic grammar if you still would like your proposal
> evaluated.
>
> Regards,
> Neal
>
> -----Original Message-----
> From: Glenn A.P.Marshall <glenn.a.marshall at gmail.com>
> Sent: Sunday, March 29, 2009 7:12 PM
> To: coin-dev at openjdk.java.net
> Subject: PROPOSAL:  open and close brace optional for single statement try,
> catch, finally, method declaration
>
> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>
> AUTHOR(S): Glenn Marshall
>
> *OVERVIEW
>
> FEATURE SUMMARY:
>
> Make open and close brace optional for single statement try, catch,
> finally, method declaration.
>
> (the relatively rarely used single statement static initializer would
> still require braces under this proposal, due to its relative rarity).
>
> MAJOR ADVANTAGE:
>
> Simple, single statement try blocks, catch blocks, and single
> statement methods (for example, getter methods) are very common in
> Java code.  Unlike if, while and do statements, the open and close
> braces are mandatory even when the target of the keyword is a single
> statement.  This requirement needlessly clutters the code with
> unneeded open and close braces, increases code complexity slightly
> and decreases readability.  Removing this requirement addresses a
> syntactic inconsistency in Java, whereby braces are required for some
> single statement keyword targets but not others.
>
> MAJOR BENEFIT:
>
> More readable code, needless syntactic 'noise' removed, consistent
> treatment of common single statement keyword targets.  Since single
> statement try, catch, method are very common, these benefits could be
> applied many times to a typical large Java program.
>
> MAJOR DISADVANTAGE:
>
> Implementation cost is not 0. Benefits are relatively minor, to be
> fair, per instance.  Single statement keyword targets still exist -
> static initializers; the syntax is still not 100%  consistent as
> regards single statement keyword targets.
>
> ALTERNATIVES:
>
> None.
>
> * EXAMPLES
>
> SIMPLE EXAMPLE:
>
> try connection.close();
> catch (SQLException se) handleException("close failed", se);
>
> ...
>
> public String getName() return name;
>
>
> ADVANCED EXAMPLE:
>
> (this proposal is very simple; there are no advanced examples)
>
> *DETAILS
>
> SPECIFICATION: Describe how the proposal affects the grammar, type
> system, and meaning of expressions and statements in the Java
> Programming Language as well as any other known impacts.
>
> The grammar would be modified to make braces optional for single
> statement try, catch, finally, method declarations.  The block still
> exists, when braces are omitted; it is a single statement.  This is
> exactly analogous to (for example) single statement while statements
> without braces.
>
> This is purely a syntactic change - the type system, meaning of
> expressions and statements remain unchanged.
>
> COMPILATION: How would the feature be compiled to class files?
>
> The simplest implementation would be for  the Java source code parser
> to recognize when the braces have been omitted and add them back,
> internally, conceptually.  This eliminates any downstream impact.
>
> TESTING: How can the feature be tested?
>
> Extend the source code samples processed by the compiler test suite
> to include  samples of code using this feature.  Remember to handle
> the null statement.
>
> LIBRARY SUPPORT: Are any supporting libraries needed for the feature?
>
> No.
>
> REFLECTIVE APIS: Do any of the various and sundry reflection APIs need
> to be updated? This list of reflective APIs includes but is not limited
> to core reflection (java.lang.Class and java.lang.reflect.*),
> javax.lang.model.*, the doclet API, and JPDA.
>
> No
>
> OTHER CHANGES: Do any other parts of the platform need be updated too?
> Possibilities include but are not limited to JNI, serialization, and
> output of the javadoc tool.
>
> No.
>
> MIGRATION: Sketch how a code base could be converted, manually or
> automatically, to use the new feature.
>
> Look for sequences of if try { <single statement>; } and replace with
> try <single statement>.
>
> Also for catch, method definitions, finally.
>
> COMPATIBILITY
> BREAKING CHANGES: Are any previously valid programs now invalid? If so,
> list one.
>
> All existing programs remain valid.
>
> EXISTING PROGRAMS: How do source and class files of earlier platform
> versions interact with the feature? Can any new overloadings occur? Can
> any new overriding occur?
>
> The semantics of existing class files are unchanged.  Source code
> that previously omitted these required braces would not compile due
> to a syntax error; this source will now compile.  Compiler test cases
> that tested this behaviour, expecting to fail, will now pass.
>
> * REFERENCES
>
> EXISTING BUGS:
>
> (none found)
>
> URL FOR PROTOTYPE (optional):
>
> No prototype at this time.
>
>
>