Early error vs. error on first call to function vs. runtime error

Brendan Eich brendan at mozilla.org
Thu Sep 27 22:54:05 PDT 2012


Oliver Hunt wrote:
> I'm generally against error on first call -- in the general case if you're able to determine a function should fail on first execution you can determine that it could fail during parsing and semantic analysis.

Ok, to play fair I should ask how you feel about any analysis that is 
not "cheap enough" to do during a parse or lex/read pass required to 
lazily compile functions on first call. What about binding analysis, 
recognizing every statically resolvable use of a definition, possibly 
making free variable uses early errors when inside module {...}?

/be
>
> --Oliver
>
>
> On Sep 27, 2012, at 9:01 PM, Brendan Eich<brendan at mozilla.org>  wrote:
>
>> Domenic Denicola wrote:
>>> As a user, not implementer, I really want early errors. Perf costs of startup are negligible especially long-term. By the time ES6 is in browsers computers and phones should be faster by enough of a factor to mitigate any costs, whereas omitting early errors hurts developers indefinitely into the future.
>> Totally agree!
>>
>> Others on TC39 made this point too. We're not near consensus, unfortunately.
>>
>> /be
>>
>>
>>> On Sep 28, 2012, at 4:02, "Brendan Eich"<brendan at mozilla.org>   wrote:
>>>
>>>> Brendan Eich wrote:
>>>>> We have not discussed error-on-first-call in this thread at all!
>>>> This needs a separate thread. The idea from last week's TC39 meeting was to have not only
>>>>
>>>> * Early error, thrown before any code in the Program (grammar goal symbol) containing the error, required by specific language in Clause 16.
>>>>
>>>> * Runtime error, all the other kinds.
>>>>
>>>> and now
>>>>
>>>> * Error on first call to a function, where the function contains what would be an early error but for the supposed cost of early error analysis.
>>>>
>>>> The last case is really just a runtime error: a function with what should be a static error becomes a booby trap: if your tests happen to miss calling it, you'll feel ok, but a user who tickles the uncovered path will get a runtime error.
>>>>
>>>> TC39 heard from some implementors who wanted to avoid more early error requirements in ES6, or at least any that require analysis, e.g. reaching definitions.
>>>>
>>>> That's fair as input to the committee, but implementation concerns are not the only ones we weigh. And we were far from agreed on adding the "Error on first call" category.
>>>>
>>>> The example you imply here would be
>>>>
>>>>   function f(a, b = c, a = d) {
>>>>   }
>>>>
>>>> and the duplicate formal a would be illegal because of the novel default-parameter syntax.
>>>>
>>>> Making f into a proximity-fused bomb does not see either good or necessary. The analysis requires to notice duplicate formals is trivial, and as I keep pointing out, ES5 already requires it:
>>>>
>>>>   function g(a, a) {
>>>>     "use strict";
>>>>   }
>>>>
>>>> This must be an early error per ES5 clause 16.
>>>>
>>>> Given the ES5-strict sunk cost, there's no added implementation tax beyond the logic conjoining duplicate detection with novel-syntax detection, which is trivial.
>>>>
>>>> It'd be good to hear from Luke on this.
>>>>
>>>> /be
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list