14.doc.html

java语言规范

Here is another example:<p>
<pre><a name="5926"></a>
class Test {
<a name="32622"></a>	public static void main(String[] args) {
<a name="50177"></a>		System.out.print("2+1=");
<a name="5927"></a>		int two = 2, three = two + 1;
<a name="5928"></a>		System.out.println(three);
<a name="50179"></a>	}
<a name="5929"></a>}
</pre><a name="17863"></a>
which compiles correctly and produces the output:
<p><pre><a name="17864"></a>2+1=3
</pre><a name="7616"></a>
The initializer for <code>three</code> can correctly refer to the variable <code>two</code> declared in an earlier
declarator, and the method invocation in the next line can correctly refer to the 
variable <code>three</code> declared earlier in the block.
<p><a name="35349"></a>
The scope of a local variable declared in a <code>for</code> statement is the rest of the <code>for</code> statement, including its own initializer.<p>
<a name="32558"></a>
If a declaration of an identifier as a local variable appears within the scope of a parameter or local variable of the same name, a compile-time error occurs. Thus the following example does not compile:<p>
<pre><a name="32645"></a>
class Test {
<a name="32646"></a>	public static void main(String[] args) {
<a name="50181"></a>		int i;
<a name="32663"></a>		for (int i = 0; i &lt; 10; i++)
<a name="32664"></a>			System.out.println(i);
<a name="32652"></a>	}
<a name="32653"></a>}
</pre><a name="32559"></a>
This restriction helps to detect some otherwise very obscure bugs. (A similar 
restriction on hiding of members by local variables was judged impractical, 
because the addition of a member in a superclass could cause subclasses to have to 
rename local variables.)
<p><a name="35322"></a>
On the other hand, local variables with the same name may be declared in two separate blocks or <code>for</code> statements neither of which contains the other. Thus:<p>
<pre><a name="17888"></a>
class Test {
<a name="17889"></a>	public static void main(String[] args) {
<a name="17890"></a>		for (int i = 0; i &lt; 10; i++)
<a name="17891"></a>			System.out.print(i + " ");
<a name="17892"></a>		for (int i = 10; i &gt; 0; i--)
<a name="17893"></a>			System.out.print(i + " ");
<a name="17894"></a>		System.out.println();
<a name="17895"></a>	}
<a name="17896"></a>}
</pre><a name="17897"></a>
compiles without error and, when executed, produces the output:
<p><pre><a name="17881"></a>0 1 2 3 4 5 6 7 8 9 10 9 8 7 6 5 4 3 2 1
</pre><a name="32673"></a>
<h3>14.3.3    Hiding of Names by Local Variables</h3>
<a name="32716"></a>
If a name declared as a local variable is already declared as a field or type name, 
then that outer declaration is hidden throughout the scope of the local variable. 
The field or type name can almost always <a href="6.doc.html#11186">(&#167;6.8)</a> still be accessed using an appropriately
qualified name. For example, the keyword <code>this</code> can be used to access a 
hidden field <code>x</code>, using the form <code>this.x</code>. Indeed, this idiom typically appears in constructors
<a href="8.doc.html#41652">(&#167;8.6)</a>:
<p><pre><a name="32566"></a>
class Pair {
<a name="32567"></a>	Object first, second;
<a name="32568"></a>	public Pair(Object first, Object second) {
<a name="32569"></a>		this.first = first;
<a name="32570"></a>		this.second = second;
<a name="32571"></a>	}
<a name="32572"></a>}
</pre><a name="32573"></a>
In this example, the constructor takes parameters having the same names as the 
fields to be initialized. This is simpler than having to invent different names for 
the parameters and is not too confusing in this stylized context. In general, however,
it is considered poor style to have local variables with the same names as 
fields.
<p><a name="32717"></a>
<h3>14.3.4    Execution of Local Variable Declarations</h3>
<a name="32574"></a>
A local variable declaration statement is an executable statement. Every time it is 
executed, the declarators are processed in order from left to right. If a declarator 
has an initialization expression, the expression is evaluated and its value is 
assigned to the variable. If a declarator does not have an initialization expression, 
then a Java compiler must prove, using exactly the algorithm given in <a href="16.doc.html#25979">&#167;16</a>, that 
every reference to the variable is necessarily preceded by execution of an assignment
to the variable. If this is not the case, then a compile-time error occurs.
<p><a name="32578"></a>
Each initialization (except the first) is executed only if the evaluation of the preceding initialization expression completes normally. Execution of the local variable declaration completes normally only if evaluation of the last initialization expression completes normally; if the local variable declaration contains no initialization expressions, then executing it always completes normally.<p>
<a name="32584"></a>
<h2>14.4    Statements</h2>
<a name="32588"></a>
There are many kinds of statements in the Java language. Most correspond to 
statements in the C and C++ languages, but some are unique to Java.
<p><a name="5958"></a>
As in C and C++, the Java <code>if</code> statement suffers from the so-called "dangling <code>else</code> problem," illustrated by this misleadingly formatted example:<p>
<pre><a name="17933"></a>
if (door.isOpen())
<a name="5960"></a>	if (resident.isVisible())
<a name="35428"></a>		resident.greet("Hello!");
<a name="5961"></a>else door.bell.ring();								// A "dangling else"
</pre><a name="5962"></a>
The problem is that both the outer <code>if</code> statement and the inner <code>if</code> statement might 
conceivably own the <code>else</code> clause. In this example, one might surmise that the programmer
intended the <code>else</code> clause to belong to the outer <code>if</code> statement. The Java 
language, like C and C++ and many languages before them, arbitrarily decree that 
an <code>else</code> clause belongs to the innermost <code>if</code> to which it might possibly belong. 
This rule is captured by the following grammar:
<p><ul><pre>
<i>Statement:<br>
	StatementWithoutTrailingSubstatement<br>
	LabeledStatement<br>
	IfThenStatement<br>
	IfThenElseStatement<br>
	WhileStatement<br>
	ForStatement
</i>
<i>StatementNoShortIf:<br>
	StatementWithoutTrailingSubstatement<br>
	LabeledStatementNoShortIf<br>
	IfThenElseStatementNoShortIf<br>
	WhileStatementNoShortIf<br>
	ForStatementNoShortIf
</i>
<i>StatementWithoutTrailingSubstatement:<br>
	Block<br>
	EmptyStatement<br>
	ExpressionStatement<br>
	SwitchStatement<br>
	DoStatement<br>
	BreakStatement<br>
	ContinueStatement<br>
	ReturnStatement<br>
	SynchronizedStatement<br>
	ThrowStatement<br>
	TryStatement
</i></pre></ul><a name="8344"></a>
The following are repeated from <a href="14.doc.html#5991">&#167;14.8</a> to make the presentation here clearer:
<p><ul><pre>
<i>IfThenStatement:<br>
</i>	<code>if ( </code><i>Expression</i><code> ) </code><i>Statement
</i>
<i>IfThenElseStatement:<br>
</i>	<code>if ( </code><i>Expression</i><code> ) </code><i>StatementNoShortIf</i><code> else </code><i>Statement
</i>
<i>IfThenElseStatementNoShortIf:<br>
</i>	<code>if ( </code><i>Expression</i><code> ) </code><i>StatementNoShortIf</i><code> else </code><i>StatementNoShortIf
</i></pre></ul><a name="5969"></a>
Statements are thus grammatically divided into two categories: those that might end in an <code>if</code> statement that has no <code>else</code> clause (a "short <code>if</code> statement") and those that definitely do not. Only statements that definitely do not end in a short <code>if</code> statement may appear as an immediate substatement before the keyword <code>else</code> in an <code>if</code> statement that does have an <code>else</code> clause. This simple rule prevents the "dangling <code>else</code>" problem. The execution behavior of a statement with the "no short <code>if</code>" restriction is identical to the execution behavior of the same kind of statement without the "no short <code>if</code>" restriction; the distinction is drawn purely to resolve the syntactic difficulty.<p>
<a name="5970"></a>
<h2>14.5    The Empty Statement</h2>
<a name="5971"></a>
An <i>empty statement</i> does nothing.
<p><ul><pre>
<i>EmptyStatement:<br>
</i>	<code>;
</code></pre></ul><a name="5973"></a>
Execution of an empty statement always completes normally.
<p><a name="78993"></a>
<h2>14.6    Labeled Statements</h2>
<a name="78994"></a>
Statements may have <i>label</i> prefixes.
<p><ul><pre>
<i>LabeledStatement:<br>
</i>	<i>Identifier</i><code> : </code><i>Statement
</i>
<i>LabeledStatementNoShortIf:<br>
</i>	<i>Identifier</i><code> : </code><i>StatementNoShortIf
</i></pre></ul><a name="78997"></a>
The <i>Identifier</i> is declared to be the label of the immediately contained <i>Statement</i>.
<p><a name="17941"></a>
Unlike C and C++, the Java language has no <code>goto</code> statement; identifier statement labels are used with <code>break</code> <a href="14.doc.html#6842">(&#167;14.13)</a> or <code>continue</code> <a href="14.doc.html#6122">(&#167;14.14)</a> statements appearing anywhere within the labeled statement.<p>
<a name="78998"></a>
A statement labeled by an identifier must not appear anywhere within another statement labeled by the same identifier, or a compile-time error will occur. Two statements can be labeled by the same identifier only if neither statement contains the other.<p>
<a name="35441"></a>
There is no restriction against using the same identifier as a label and as the name of a package, class, interface, method, field, parameter, or local variable. Use of an identifier to label a statement does not hide a package, class, interface, method, field, parameter, or local variable with the same name. Use of an identifier &#32;as a local variable or as the parameter of an exception handler <a href="14.doc.html#79311">(&#167;14.18)</a> does not hide a statement label with the same name.<p>
<a name="79000"></a>
A labeled statement is executed by executing the immediately contained <i>Statement</i>. If the statement is labeled by an <i>Identifier</i> and the contained <i>Statement</i> completes abruptly because of a <code>break</code> with the same <i>Identifier</i>, then the labeled statement completes normally. In all other cases of abrupt completion of the <i>Statement</i>, &#32;the labeled statement completes abruptly for the same reason.<p>
<a name="5984"></a>
<h2>14.7    Expression Statements</h2>
<a name="5985"></a>
Certain kinds of expressions may be used as statements by following them with 
semicolons:
<p><ul><pre>
<i>ExpressionStatement:<br>
</i>	<i>StatementExpression</i><code> ;
</code>
<i>StatementExpression:<br>
</i>	<i>Assignment<br>
	PreIncrementExpression<br>