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

Oliver Hunt oliver at apple.com
Fri Sep 28 07:59:16 PDT 2012


On Sep 27, 2012, at 10:54 PM, Brendan Eich <brendan at mozilla.org> wrote:

> 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 {...}?

I am still not sure whether modules are expected to have a containing scope, but either way noticing free var references during parsing in not a problem (why would it be?)

the reason I didn't say "all cases" is because resolution of an unbound global property obviously can't be determined during parsing, it also doesn't make sense to fail before the access (ignoring backwards compat issues entirely here the obviate this problem).

I'm not sure what classes of error would warrant exception on initial execution vs. just failing on sema, could you give an example?

--Oliver

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