It woulds also be good to create a bugs.ecmascript.org ticket for this. That will ensure it doesn't get lost
Allen On Apr 15, 2014, at 8:25 AM, Allen Wirfs-Brock wrote: > yes, It's on my "get back to soon" list... > > Allen > > On Apr 14, 2014, at 12:36 AM, Andy Wingo wrote: > >> Hi, >> >> A re-ping on this issue. Probably the relevant people were distracted >> by TC39 last week. >> >> On Tue 08 Apr 2014 14:47, Andy Wingo <[email protected]> writes: >> >>> Hello, >>> >>> The current ES6 draft seems to specify that if a running generator >>> throws an exception, that its state moves to "completed". It seems to >>> specify this in ยง25.3.3.1, `GeneratorStart'. (Oddly, the procedure >>> described in `GeneratorResume' can return to `GeneratorStart'; spec >>> strangeness). Anyway, that means that: >>> >>> function *foo() { yield 1; yield 2 } >>> var iter = foo() >>> iter.next() // => { value: 1, done: false } >>> iter.throw(42) // uncaught exception: 42 >>> >>> Up to here all good. And then we have, according to the spec: >>> >>> iter.next() // => { value: undefined, done: true } >>> >>> I find this very strange. I would have expected an exception of the >>> kind "generator is already running", as indeed we entered the running >>> state but never moved out of that state. >>> >>> I think that nonlocal exits from within generators should not move the >>> state to "completed", and should leave them as "suspendedStart". Beyond >>> a subjective impression of strangeness, which not all may share, this >>> part of the specification requires that the continuation of all >>> GeneratorResume() invocations include a try/catch to set the generator >>> state to "completed" if the activation resumes and then exits >>> nonlocally. >>> >>> Of course using "iter.throw" is the easy way to cause an exception, but >>> it could happen within some function called by the generator. But if we >>> decide to remove the try/catch from around the GeneratorResume, it might >>> make sense to also remove the suspendedStart -> completed transition >>> that is special-cased in Generator.prototype.throw. >>> >>> In summary: the completed-on-exception state change is of little utility >>> but causes overhead in generator implementations in the form of the >>> mandatory try/catch around GeneratorResume and so it should be removed >>> IMO. >>> >>> If it is removed we could also consider removing the >>> suspendedStart->completed state change on Generator.prototype.throw. If >>> that were done we could remove the suspendedStart state entirely; dead >>> spec elimination ;) >>> >>> WDYT? >>> >>> Regards, >>> >>> Andy >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
