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

Glenn A. Marshall glenn.a.marshall at gmail.com
Mon Mar 30 04:45:42 PDT 2009

  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.

  1. 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 { ; } and replace with try . 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.

More information about the coin-dev mailing list