Exceptional exits from generators

[Allen Wirfs-Brock]

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
>