Prev: How can I get visible area on Android browser?
Next: Singleton vs Singleton
From: John G Harris on 25 Jan 2010 15:59
On Mon, 25 Jan 2010 at 20:05:02, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> [...] What the browser, etc, does with the syntax error after reporting
>> it is outside the language spec, but it's preferable for it to refuse to
>> run the program.
>
>Incorrect.
>It is vice-versa: The browser (in general: the runtime
>environment) runs a script engine, which must not (continue to) run the
>source code as a /Program/ if it encounters a syntax error. However, how it
>reports the syntax error, and how the runtime environment visualizes it, is
>beyond the scope of the Specification. Cf. ES3F/ES5, sections 14 and 16.

Not in my copy of ES3 and ES5. Both say :

"An implementation shall report all errors as specified, except for the
following:"

Obviously they don't say how the report is displayed.

I don't see any mention of stopping.

John
--
John Harris
From: Russell Potter on 25 Jan 2010 17:16

John,

> It really is a syntax error, not just best practice. The syntax
> specification says :
>
> ThrowStatement :
> throw [no LineTerminator here] Expression ;
>
> so 'throw' followed by a line terminator is not allowed, nor is 'throw'
> followed by a semicolon.
>
> You're right that restricted productions have a further rule that I'd
> overlooked. It causes a lonely 'return' to be followed by a semicolon,
> always, which is legal, and a lonely 'throw' to be turned into a syntax
> error. What the browser, etc, does with the syntax error after reporting
> it is outside the language spec, but it's preferable for it to refuse to
> run the program.

Thanks *very* much for that answer: the spec's defined behaviour
(as you've dust it to given me) in that sitation, regardless of how
much or little you or I agree with the veracity iof that behaviour,
id what I'm really looking for.

Russell
From: Thomas 'PointedEars' Lahn on 25 Jan 2010 17:33
John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> [...] What the browser, etc, does with the syntax error after reporting
>>> it is outside the language spec, but it's preferable for it to refuse
>>> to run the program.
>>
>> Incorrect. It is vice-versa: The browser (in general: the runtime
>> environment) runs a script engine, which must not (continue to) run the
>> source code as a /Program/ if it encounters a syntax error. However,
>> how it reports the syntax error, and how the runtime environment
>> visualizes it, is beyond the scope of the Specification. Cf. ES3F/ES5,
>> sections 14 and 16.
>
> Not in my copy of ES3 and ES5. Both say :

Know that there is ES3 and ES3F(inal).

> "An implementation shall report all errors as specified, except for the
> following:"
>
> Obviously they don't say how the report is displayed.

Which is what I said, not you.

> I don't see any mention of stopping.

Section 14 says how a program must be parsed, and there is:

| [...]
|
| The production SourceElements : SourceElements SourceElement
| is evaluated as follows:
|
| 1. Evaluate SourceElements.
| 2. If Result(1) is an abrupt completion, return Result(1)
| 3. Evaluate SourceElement.
| 4. Return Result(3).

(Quoted from ES3F; ES5 uses a different, IMHO more complicated, wording
with the same meaning.)

A syntax error creates an abrupt completion, that is, (per section 8.9), a
value of the internal Completion type (`(type, value, target)'; it was
asked about yesterday) with the type being any other than `normal'.

Per section 16, a conforming implementation is only free to defer reporting
syntax errors until execution reaches its position ("until the relevant
statement is reached"); however, it must stop afterwards (it should be
quite obvious that a syntax error is a fatal error that cannot be
automatically corrected so that the rest of the /Program/ still makes
sense).


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: John G Harris on 27 Jan 2010 15:27
On Mon, 25 Jan 2010 at 23:33:13, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>>> [...] What the browser, etc, does with the syntax error after reporting
>>>> it is outside the language spec, but it's preferable for it to refuse
>>>> to run the program.
>>>
>>> Incorrect. It is vice-versa: The browser (in general: the runtime
>>> environment) runs a script engine, which must not (continue to) run the
>>> source code as a /Program/ if it encounters a syntax error. However,
>>> how it reports the syntax error, and how the runtime environment
>>> visualizes it, is beyond the scope of the Specification. Cf. ES3F/ES5,
>>> sections 14 and 16.
>>
>> Not in my copy of ES3 and ES5. Both say :
>
>Know that there is ES3 and ES3F(inal).
>
>> "An implementation shall report all errors as specified, except for the
>> following:"
>>
>> Obviously they don't say how the report is displayed.
>
>Which is what I said, not you.

I said report, deliberately. You're the one who started talking about
displaying.


>> I don't see any mention of stopping.
>
>Section 14 says how a program must be parsed, and there is:
>
>| [...]
>|
>| The production SourceElements : SourceElements SourceElement
>| is evaluated as follows:
>|
>| 1. Evaluate SourceElements.
>| 2. If Result(1) is an abrupt completion, return Result(1)
>| 3. Evaluate SourceElement.
>| 4. Return Result(3).
>
>(Quoted from ES3F; ES5 uses a different, IMHO more complicated, wording
>with the same meaning.)
>
>A syntax error creates an abrupt completion, that is, (per section 8.9), a
>value of the internal Completion type (`(type, value, target)'; it was
>asked about yesterday) with the type being any other than `normal'.

The type in an abrupt completion doesn't include 'error' (in ES3).


>Per section 16, a conforming implementation is only free to defer reporting
>syntax errors until execution reaches its position ("until the relevant
>statement is reached"); however, it must stop afterwards

It stops in order to report the error. What happens next isn't
specified.


>(it should be
>quite obvious that a syntax error is a fatal error that cannot be
>corrected so that the rest of the /Program/ still makes
>sense).

It may be obvious to you and me but half the world's web designers would
be out of work if HTML syntax errors stopped the page being displayed.
I've known a version of IE that ran the javascript after a javascript
syntax error. The next version displayed a completely white page.

John
--
John Harris
From: Thomas 'PointedEars' Lahn on 27 Jan 2010 18:47
John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> John G Harris wrote:
>>>>> [...] What the browser, etc, does with the syntax error after
>>>>> reporting it is outside the language spec, but it's preferable
>>>>> for it to refuse to run the program.
>>>> Incorrect. It is vice-versa: The browser (in general: the runtime
>>>> environment) runs a script engine, which must not (continue to) run
>>>> the source code as a /Program/ if it encounters a syntax error.
>>>> However, how it reports the syntax error, and how the runtime
>>>> environment visualizes it, is beyond the scope of the Specification.
>>>> Cf. ES3F/ES5, sections 14 and 16.
>>> Not in my copy of ES3 and ES5. Both say :
>> [...]
>>> "An implementation shall report all errors as specified, except for the
>>> following:"
>>>
>>> Obviously they don't say how the report is displayed.
>> Which is what I said, not you.
>
> I said report, deliberately. You're the one who started talking about
> displaying.

Well, "report" is quite an ambiguous word, isn't it?

>>> I don't see any mention of stopping.
>> Section 14 says how a program must be parsed, and there is:
>>
>>| [...]
>>|
>>| The production SourceElements : SourceElements SourceElement
>>| is evaluated as follows:
>>|
>>| 1. Evaluate SourceElements.
>>| 2. If Result(1) is an abrupt completion, return Result(1)
>>| 3. Evaluate SourceElement.
>>| 4. Return Result(3).
>>
>> (Quoted from ES3F; ES5 uses a different, IMHO more complicated, wording
>> with the same meaning.)
>>
>> A syntax error creates an abrupt completion, that is, (per section 8.9),
>> a value of the internal Completion type (`(type, value, target)'; it was
>> asked about yesterday) with the type being any other than `normal'.
>
> The type in an abrupt completion doesn't include 'error' (in ES3).

No, but it includes `throw', and if you had read more carefully you would
have observed several occurrences of `throw' near `SyntaxError' in the
Specification prose.

>> Per section 16, a conforming implementation is only free to defer
>> reporting syntax errors until execution reaches its position ("until the
>> relevant statement is reached"); however, it must stop afterwards
>
> It stops in order to report the error. What happens next isn't
> specified.

Incorrect.

>> (it should be quite obvious that a syntax error is a fatal error that
>> cannot be corrected so that the rest of the /Program/ still make
>> sense).
>
> It may be obvious to you and me but half the world's web designers would
> be out of work if HTML syntax errors stopped the page being displayed.

Apples, oranges. We are talking about a programming language here; it is
designed to compute, and its computations need to be correct and reliable.
By contrast, HTML is a markup language; it is designed to cause a document
to be displayed by a renderer, and approximate display is acceptable (not
to mention the vivid history of HTML).

However, there are also markup languages where a syntax error allows to
happen exactly what you describe, most notably XHTML served as
application/xhtml+xml in a Gecko-based browser if the XML parser encounters
not well-formed markup (IOW, a syntax error).

> I've known a version of IE that ran the javascript after a javascript
> syntax error. The next version displayed a completely white page.

That is a pretty useless statement. However, HTML SCRIPT elements are
special in that depends on the runtime environment whether a script syntax
error in one SCRIPT element prevents execution of code in following SCRIPT
elements and event-listener code, i.e. whether the content of one SCRIPT
element is regarded a /Program/ of its own. We have already discussed this
several times.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How can I get visible area on Android browser?
Next: Singleton vs Singleton