A Statement can be part of a LabelledStatement, which itself can be part of a LabelledStatement, and so on. The labels introduced this way are collectively referred to as the “current label set” when describing the semantics of individual statements. A LabelledStatement has no semantic meaning other than the introduction of a label to a label set. The label set of an IterationStatement or a SwitchStatement initially contains the single element empty. The label set of any other statement is initially empty.
The result of evaluating a Statement is always a Completion value.
NOTE Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations. Because of these irreconcilable differences, the use of a FunctionDeclaration as a Statement results in code that is not reliably portable among implementations. It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. Future editions of ECMAScript may define alternative portable means for declaring functions in a Statement context.
{
StatementListopt }
The production Block : {
}
is evaluated as follows:
The production Block : {
StatementList }
is evaluated as follows:
The production StatementList : Statement is evaluated as follows:
The production StatementList : StatementList Statement is evaluated as follows:
NOTE Steps 5 and 6 of the above algoritm ensure that the value of a StatementList is the value of the last value producing Statement in the StatementList. For example, the following calls to the eval
function all return the value
1:
eval("1;;;;;")
eval("1;{}")
eval("1;var a;")
var
VariableDeclarationList ;
,
VariableDeclaration,
VariableDeclarationNoIn=
AssignmentExpression=
AssignmentExpressionNoInA variable statement declares variables that are created as defined in 10.5. Variables are initialised to undefined when created. A variable with an Initialiser is assigned the value of its AssignmentExpression when the VariableStatement is executed, not when the variable is created.
The production VariableStatement : var
VariableDeclarationList ;
is evaluated as
follows:
The production VariableDeclarationList :VariableDeclaration
is evaluated as follows:
The production VariableDeclarationList : VariableDeclarationList ,
VariableDeclaration is
evaluated as follows:
The production VariableDeclaration : Identifier is evaluated as follows:
The production VariableDeclaration : Identifier Initialiser is evaluated as follows:
NOTE The String value of a VariableDeclaration is used in the evaluation of for-in statements (12.6.4).
If a VariableDeclaration is nested within a with statement and the Identifier in the VariableDeclaration is the same as a property name of the binding object of the with statement's object environment record, then step 4 will assign value to the property instead of to the VariableEnvironment binding of the Identifier.
The production Initialiser : =
AssignmentExpression is evaluated as follows:
The VariableDeclarationListNoIn, VariableDeclarationNoIn and InitialiserNoIn productions are evaluated in the same manner as the VariableDeclarationList, VariableDeclaration and Initialiser productions except that the contained VariableDeclarationListNoIn, VariableDeclarationNoIn, InitialiserNoIn and AssignmentExpressionNoIn are evaluated instead of the contained VariableDeclarationList, VariableDeclaration, Initialiser and AssignmentExpression, respectively.
It is a SyntaxError if a VariableDeclaration or VariableDeclarationNoIn occurs within strict code and its Identifier is either "eval"
or "arguments".
;
The production EmptyStatement : ;
is evaluated as follows:
{
, function
}] Expression ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. Also, an ExpressionStatement cannot start with the function
keyword because that might make it
ambiguous with a FunctionDeclaration.
The production ExpressionStatement : [lookahead ∉ {{
, function
}] Expression ;
is evaluated as follows:
if
(
Expression )
Statement else
Statementif
(
Expression )
StatementEach else
for which the choice of associated if
is ambiguous shall be associated with the nearest
possible if that would otherwise have no corresponding else
.
The production IfStatement : if
(
Expression )
Statement else
Statement is evaluated as follows:
The production IfStatement : if
(
Expression )
Statement
is evaluated as follows:
do
Statement while
(
Expression );
while
(
Expression )
Statementfor
(
ExpressionNoInopt ;
Expressionopt ;
Expressionopt )
Statementfor
(
var
VariableDeclarationListNoIn ;
Expressionopt ;
Expressionopt )
Statementfor
(
LeftHandSideExpression in
Expression )
Statementfor
(
var
VariableDeclarationNoIn in
Expression )
StatementThe production do
Statement while
(
Expression );
is evaluated as follows:
The production IterationStatement : while
(
Expression )
Statement is evaluated as follows:
The production
IterationStatement : for
(
ExpressionNoInopt ;
Expressionopt ;
Expressionopt
)
Statement
is evaluated as follows:
The production
IterationStatement : for
(
var
VariableDeclarationListNoIn
;
Expressionopt ;
Expressionopt )
Statement
is evaluated
as follows:
The production IterationStatement : for
(
LeftHandSideExpression in
Expression )
Statement is evaluated as follows:
The production
IterationStatement : for
(
var
VariableDeclarationNoIn
in
Expression )
Statement
is evaluated as follows:
The mechanics and order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is not specified. Properties of the object being enumerated may be deleted during enumeration. If a property that has not yet been visited during enumeration is deleted, then it will not be visited. If new properties are added to the object being enumerated during enumeration, the newly added properties are not guaranteed to be visited in the active enumeration. A property name must not be visited more than once in any enumeration.
Enumerating the properties of an object includes enumerating properties of its prototype, and the prototype of the prototype, and so on, recursively; but a property of a prototype is not enumerated if it is “shadowed” because some previous object in the prototype chain has a property with the same name. The values of [[Enumerable]] attributes are not considered when determining if a property of a prototype object is shadowed by a previous object on the prototype chain.
NOTE See NOTE 11.13.1.
continue
;
continue
[no LineTerminator here] Identifier ;
A program is considered syntactically incorrect if either of the following is true:
The program contains a continue
statement without the optional Identifier, which is not nested,
directly or indirectly (but not crossing function boundaries), within an IterationStatement.
The program contains a continue
statement with the optional Identifier, where Identifier
does not appear in the label set of an enclosing (but not crossing function boundaries) IterationStatement.
A ContinueStatement without an Identifier is evaluated as follows:
A ContinueStatement with the optional Identifier is evaluated as follows:
break
;
break
[no LineTerminator here] Identifier ;
A program is considered syntactically incorrect if either of the following is true:
The program contains a break
statement without the optional Identifier, which is not nested,
directly or indirectly (but not crossing function boundaries), within an IterationStatement or a
SwitchStatement.
The program contains a break
statement with the optional Identifier, where Identifier does
not appear in the label set of an enclosing (but not crossing function boundaries) Statement.
A BreakStatement without an Identifier is evaluated as follows:
A BreakStatement with an Identifier is evaluated as follows:
return
;
return
[no LineTerminator here] Expression ;
An ECMAScript program is considered syntactically incorrect if it contains a return
statement that is not
within a FunctionBody. A return
statement causes a function to cease execution and return
a value to the caller. If Expression is omitted, the return value is undefined. Otherwise, the
return value is the value of Expression.
A ReturnStatement is evaluated as follows:
with
(
Expression )
StatementThe with
statement adds an object environment record for a computed object to the lexical environment of the current execution context. It then executes a statement using this augmented
lexical environment. Finally, it restores the original lexical
environment.
The production WithStatement : with
(
Expression )
Statement is evaluated as follows:
NOTE No matter how control leaves the embedded Statement, whether normally or by some form of abrupt completion or exception, the LexicalEnvironment is always restored to its former state.
Strict mode code may not include a WithStatement. The occurrence of a WithStatement in such a context is treated as a SyntaxError.
switch
(
Expression )
CaseBlock{
CaseClausesopt }
{
CaseClausesopt DefaultClause CaseClausesopt }
case
Expression :
StatementListoptdefault
:
StatementListoptThe production SwitchStatement : switch
(
Expression )
CaseBlock is evaluated as follows:
The production CaseBlock : {
CaseClausesopt }
is given an input parameter,
input, and is evaluated as follows:
The production CaseBlock : {
CaseClausesopt DefaultClause CaseClausesopt }
is given an input parameter, input, and
is evaluated as follows:
The production CaseClause : case
Expression :
StatementListopt is
evaluated as follows:
NOTE Evaluating CaseClause does not execute the associated StatementList. It simply evaluates the Expression and returns the value, which the CaseBlock algorithm uses to determine which StatementList to start executing.
:
StatementA Statement may be prefixed by a label. Labelled statements are only used in conjunction with
labelled break
and continue
statements. ECMAScript has no goto
statement.
An ECMAScript program is considered syntactically incorrect if it contains a LabelledStatement that is enclosed by a LabelledStatement with the same Identifier as label. This does not apply to labels appearing within the body of a FunctionDeclaration that is nested, directly or indirectly, within a labelled statement.
The production Identifier : Statement is evaluated by adding Identifier to the label set of Statement and then evaluating Statement. If the LabelledStatement itself has a non-empty label set, these labels are also added to the label set of Statement before evaluating it. If the result of evaluating Statement is (break, V, L) where L is equal to Identifier, the production results in (normal, V, empty).
Prior to the evaluation of a LabelledStatement, the contained Statement is regarded as possessing an empty label set, unless it is an IterationStatement or a SwitchStatement, in which case it is regarded as possessing a label set consisting of the single element, empty.
throw
[no LineTerminator here] Expression ;
The production ThrowStatement : throw
[no LineTerminator here] Expression ;
is evaluated as follows:
try
Block Catchtry
Block Finallytry
Block Catch Finallycatch
(
Identifier )
Blockfinally
BlockThe try
statement encloses a block of code in which an exceptional condition can occur, such as a runtime
error or a throw
statement. The catch
clause provides the exception-handling code. When a catch
clause catches an exception, its Identifier is bound to that exception.
The production TryStatement : try
Block Catch is evaluated as follows:
The production TryStatement : try
Block Finally is evaluated as follows:
The production TryStatement : try
Block Catch Finally is
evaluated as follows:
The production Catch : catch
(
Identifier )
Block is
evaluated as follows:
NOTE No matter how control leaves the Block the LexicalEnvironment is always restored to its former state.
The production Finally : finally
Block is evaluated as follows:
It is a SyntaxError if a TryStatement with a Catch occurs within
strict code and the Identifier of the Catch
production is either "eval"
or "arguments".
debugger
;
Evaluating the DebuggerStatement production may allow an implementation to cause a breakpoint when run under a debugger. If a debugger is not present or active this statement has no observable effect.
The production DebuggerStatement : debugger
;
is evaluated as follows: