Prev: FAQ Topic - Why is my Ajax page not updated properly when using an HTTP GET request in Internet Explorer? (2010-07-07)
Next: comp.lang.javascript Daily Postings
From: Garrett Smith on 6 Jul 2010 20:12
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
From: Richard Cornford on 7 Jul 2010 08:22
On Jul 7, 1:12 am, Garrett Smith wrote:
> I recently came across a piece of code that defines
> SyntaxError.
<snip>
> 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.
From: Garrett Smith on 7 Jul 2010 14:11
On 2010-07-07 05:22 AM, Richard Cornford wrote:
> On Jul 7, 1:12 am, Garrett Smith wrote:
>> I recently came across a piece of code that defines
>> SyntaxError.
> <snip>
>> 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 ... .
>

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

>> 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.
>

Or Function constructor and possibly host methods like setTimeout.

>> 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.
>

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.
 | 
Pages: 1
Prev: FAQ Topic - Why is my Ajax page not updated properly when using an HTTP GET request in Internet Explorer? (2010-07-07)
Next: comp.lang.javascript Daily Postings