Redefined NativeError Types and Runtime Errors

[Garrett Smith]

I recently came across a piece of code that defines SyntaxError. That
first jumped out at me as being really wrong. After about 5 seconds, I
got to thinking about the implications of doing that.

Basically, the code is something like:

| function SyntaxError(message, line, col) {
| this.col = col;
| this.line = line;
| this.message = message;
| }

The (overly commented) code is here:

http://github.com/nzakas/parser-lib/blob/new-css-lexer/src/util/SyntaxError.js

Now I got to wondering that when a SyntaxError occurs, should it throw
the redefined SyntaxError or should it throw a SyntaxError as defined in
the specification? As I understand the spec, it should throw the error
defined in the specification:
e error that must be thrown?

| 15.11.7 NativeError Object Structure
| When an ECMAScript implementation detects a runtime error, it throws
| an instance of one of the NativeError
| objects defined in 15.11.6. Each of these objects has the structure
| described below, differing only in the name
| used as the constructor name instead of NativeError, in the name
| property of the prototype object, and in the
| implementation-defined message property of the prototype object.

The same question can be asked for any of the NativeError types
(TypeError, ReferenceError, etc).

However, if there is an instanceof (or equivalent) check to inspect a
thrown error, that would fail:

function SyntaxError(){}

try {
eval("+++");
} catch(ex) {
alert(ex instanceof SyntaxError);
}

Should result "false".

Garrett

 

[Richard Cornford]

I recently came across a piece of code that defines
SyntaxError.

Now I got to wondering that when a SyntaxError occurs, should
it throw the redefined SyntaxError or should it throw a
SyntaxError as defined in the specification? As I understand
the spec, it should throw the error defined in the specification:

The error thrown is going to be the one defined in the specification,
not the product of applying the - new - operator to a possible
arbitrary function assigned to one of the error constructor
Identifiers. Logically that is necessary as if you, for example,
assigned null to TypeError then the TypeError thrown at step 3 in the
- new - algorithm would result in the throwing of a TypeError at the
attempt to instantiate the TypeError, and on and on ... .

e error that must be thrown?

| 15.11.7 NativeError Object Structure
| When an ECMAScript implementation detects a runtime error,

Presumably any issues with a runtime SyntaxError only apply to the use
of eval, the function constructor and regular expression constructor.
All other SyntaxErrors are (arguably) not runtime errors.

| it throws an instance of one of the NativeError
| objects defined in 15.11.6.

That is the line; "objects defined in 15.11.6", as opposed to 'as if
by the use of new NativeError' (or the like).

| Each of these objects has the structure
| described below, differing only in the name used as the
| constructor name instead of NativeError, in the name
| property of the prototype object, and in the
| implementation-defined message property of the prototype object.

The same question can be asked for any of the NativeError types
(TypeError, ReferenceError, etc).

With the same answer.

However, if there is an instanceof (or equivalent) check to
inspect a thrown error, that would fail:

<snip>

It would, but that is an inherent limitation of javascript's -
instancof - operator. A runtime relationship is only of use in a
dynamic language when you know that it will hold. If there is any
(unknowable) third party code involved (from advertising, importing
'popular' libraries from third party servers, mashups, etc.) then the
outcome of - instanceof - is uncertain.

But then, javascript's exception handling is extremely poor in
general, with identifying any errors caught being one of its bigger
problems. Generally it has got to be better to avoid all the exception
handling issues by testing potential error throwing conditions before
they happen, and so avoid provoking the errors.

Richard.

 

[Garrett Smith]

The error thrown is going to be the one defined in the specification,
not the product of applying the - new - operator to a possible
arbitrary function assigned to one of the error constructor
Identifiers. Logically that is necessary as if you, for example,
assigned null to TypeError then the TypeError thrown at step 3 in the
- new - algorithm would result in the throwing of a TypeError at the
attempt to instantiate the TypeError, and on and on ... .

to the point of freeze or crash -- got it.

Presumably any issues with a runtime SyntaxError only apply to the use
of eval, the function constructor and regular expression constructor.
All other SyntaxErrors are (arguably) not runtime errors.

Or Function constructor and possibly host methods like setTimeout.

<snip>

It would, but that is an inherent limitation of javascript's -
instancof - operator. A runtime relationship is only of use in a
dynamic language when you know that it will hold. If there is any
(unknowable) third party code involved (from advertising, importing
'popular' libraries from third party servers, mashups, etc.) then the
outcome of - instanceof - is uncertain.

True, but what I was getting at was that `ex instanceof SyntaxError`
would necessarily result false for that error check where `ex` was
someting caused where the interpreter came across syntactically invalid
code (as in the eval example)

But then, javascript's exception handling is extremely poor in
general, with identifying any errors caught being one of its bigger
problems. Generally it has got to be better to avoid all the exception
handling issues by testing potential error throwing conditions before
they happen, and so avoid provoking the errors.

That's never been a problem for me.

Turns out the code gets combined and put a closure, so would not replace
global SyntaxError. Though I see instanceof check, too, in the current
`_rulesetEnd`.

http://github.com/nzakas/parser-lib/blob/new-css-lexer/build/parserlib.js

Other than that, I've not looked at it for more than a minute.