Skip to content

16 Error Handling and Language Extensions

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 parsing that Script in ParseScript. 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.2, 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.2, 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).

16.1 HostReportErrors ( errorList )

HostReportErrors is an implementation-defined abstract operation that allows host environments to report parsing errors, early errors, and runtime errors.

An implementation of HostReportErrors must complete normally in all cases. The default implementation of HostReportErrors is to unconditionally return an empty normal completion.

Note

errorList will be a List of ECMAScript language values. If the errors are parsing errors or early errors, these will always be SyntaxError or ReferenceError objects. Runtime errors, however, can be any ECMAScript value.

16.2 Forbidden Extensions

An implementation must not extend this specification in the following ways:

  • ECMAScript function objects defined using syntactic constructors in strict mode code must not be created with own properties named "caller" or "arguments". Such own properties also must not be created for function objects defined using an ArrowFunction, MethodDefinition, GeneratorDeclaration, GeneratorExpression, AsyncGeneratorDeclaration, AsyncGeneratorExpression, ClassDeclaration, ClassExpression, AsyncFunctionDeclaration, AsyncFunctionExpression, or AsyncArrowFunction regardless of whether the definition is contained in strict mode code. Built-in functions, strict functions created using the Function constructor, generator functions created using the Generator constructor, async functions created using the AsyncFunction constructor, and functions created using the bind method also must not be created with such own properties.
  • If an implementation extends any function object 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.
  • Neither mapped nor unmapped arguments objects may be created with an own property named "caller".
  • 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, %TypedArray%.prototype.toLocaleString.
  • 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 immediately follow source text that matches the BindingIdentifier nonterminal symbol.
  • When processing strict mode code, the syntax of NumericLiteral must not be extended to include prod-annexB-LegacyOctalIntegerLiteral and the syntax of DecimalIntegerLiteral must not be extended to include prod-annexB-NonOctalDecimalIntegerLiteral as described in B.1.1.
  • TemplateCharacter must not be extended to include prod-annexB-LegacyOctalEscapeSequence as defined in B.1.2.
  • When processing strict mode code, the extensions defined in B.3.2, B.3.3, B.3.4, and B.3.6 must not be supported.
  • When parsing for the Module goal symbol, the lexical grammar extensions defined in B.1.3 must not be supported.