Exceptional exits from generators

[Allen Wirfs-Brock]

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 <wingo at igalia.com> 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
>>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140415/267d0cb4/attachment.html>