An implementation must report most errors at the time the relevant ECMAScript language construct is evaluated. An early
error is an error that can be detected and reported prior to the evaluation of any construct in the Script containing the error. The presence of an early error prevents the evaluation of the construct. An
implementation must report early errors in a Script as part of the ScriptEvaluationJob for that Script. Early errors in a Module are reported at the point when the Module would be evaluated and the Module is never initialized. Early errors in eval code are reported at the time eval
is
called and prevent evaluation of the eval code. All errors that are not early errors are runtime errors.
An implementation must report as an early error any occurrence of a condition that is listed in a “Static Semantics: Early Errors” subclause of this specification.
An implementation shall not treat other kinds of errors as early errors even if the compiler can prove that a construct cannot execute without error under any circumstances. An implementation may issue an early warning in such a case, but it should not report the error until the relevant construct is actually executed.
An implementation shall report all errors as specified, except for the following:
Except as restricted in 16.1, an implementation may extend Script
syntax, Module syntax, and regular expression pattern or flag syntax. To permit this, all operations (such as
calling eval
, using a regular expression literal, or using the Function
or RegExp
constructor) that are allowed to throw SyntaxError are permitted to exhibit implementation-defined behaviour
instead of throwing SyntaxError when they encounter an implementation-defined extension to the script syntax or
regular expression pattern or flag syntax.
Except as restricted in 16.1, an implementation may provide additional types, values, objects, properties, and functions beyond those described in this specification. This may cause constructs (such as looking up a variable in the global scope) to have implementation-defined behaviour instead of throwing an error (such as ReferenceError).
An implementation may define behaviour other than throwing RangeError for toFixed
,
toExponential
, and toPrecision
when the fractionDigits or precision argument
is outside the specified range.
An implementation must not extend this specification in the following ways:
Other than as defined in this specification, ECMAScript Function objects defined using syntactic constructors in strict mode code must not be created with own properties named "caller"
or
"arguments"
other than those that are created by applying the AddRestrictedFunctionProperties abstract operation (9.2.7) to the function. Such own properties also must not be created for
function objects defined using an ArrowFunction, MethodDefinition, GeneratorDeclaration, GeneratorExpression, ClassDeclaration, or ClassExpression regardless of whether the definition
is contained in strict mode code. Built-in functions, strict mode functions
created using the Function
constructor, generator functions created using the Generator
constructor, and functions created using the bind
method also must not be created with such own
properties.
If an implementation extends non-strict or built-in function objects with an own property named "caller"
the value of that property, as observed using [[Get]] or [[GetOwnProperty]], must not be a strict function object. If it
is an accessor property, the function that is the value of the property's [[Get]] attribute must never return a
strict function when called.
The behaviour of the following methods must not be extended except as specified in ECMA-402: Object.prototype.toLocaleString
, Array.prototype.toLocaleString
, Number.prototype.toLocaleString
, Date.prototype.toLocaleDateString
, Date.prototype.toLocaleString
, Date.prototype.toLocaleTimeString
, String.prototype.localeCompare
.
The RegExp pattern grammars in 21.2.1 and B.1.4 must not be extended to recognize any of the source characters A-Z or a-z as IdentityEscape[U] when the U grammar parameter is present.
The Syntactic Grammar must not be extended in any manner that allows the token :
to immediate follow
source text that matches the BindingIdentifier nonterminal symbol.
When processing strict mode code, the syntax of NumericLiteral must not be extended to include LegacyOctalIntegerLiteral as defined in B.1.1.
TemplateCharacter (11.8.6) must not be extended to include LegacyOctalEscapeSequence as defined in B.1.2.
When processing strict mode code, the extensions defined in B.3.1, B.3.2, B.3.3, and B.3.4 must not be supported.
When parsing for the Module goal symbol, the lexical grammar extensions defined in B.1.3 must not be supported.