semantics of yield* in throw case

[GeorgNeis]

In the semantics of yield* (14.4.14) in step 5.b.ii.5.b (the throw case), it returns a return completion record.

If I understand correctly, this means that if I define

function* inner() { try {yield 1} catch(e) {return}; yield 2 }
function* outer() { yield* inner(); yield 3 }
x = outer()

then I should get the following interaction:

> x.next()
{value: 1, done: false}
> x.throw("bla")
{value: undefined, done: true}

Is this intended?

V8 and Firefox behave as if 5.b.ii.5.b would just return a normal completion (like in 5.a.iii):

> x.next()
{value: 1, done: false}
> x.throw("bla")
{value: 3, done: false}

Edge does something else entirely:

> x.next()
{value: 1, done: false}
> x.throw("bla")
Exception: bla

[zenparsing]

It looks to me like this is a spec bug, and 5.b.ii.5.a should just say

• Return ? IteratorValue(innerResult).

[zenparsing]

It looks to me like this is a spec bug, and 5.b.ii.5.a should just say

• Return ? IteratorValue(innerResult).

[allenwb]

see see https://bugs.ecmascript.org/show_bug.cgi?id=3526

The spec. originally (or at least at one time, read the whole bug thread) had the equivalent to @zenparsing’s proposed change. That was replaced with the current behavior as a fix for Comment #8. This change added both steps 5.b.ii.5.a&b (using the current draft steps) and 5.c.vii.1&2.

But it appears that the 5.b.ii.5.a&b change may have been unnecessary as Comment #8 is about invoking return rather than throw on the outer iterator. Basically that says that the current V8&FF semantics make the most sense and @zenparsing's fix is appropriate. The Edge semantics seem wrong as the exception has already been handle by the inner catch.

But this is all pretty subtle stuff, particularly when you get finally blocks involved. I recall a discussion on either es-discuss or in TC39 meeting notes where the conclusion was that totally transparent delegation via yield* (as originally envisioned) was impossible because of issues related to things like this. I haven't found those notes yet but it would be nice to review them to see if they contain anything that relates to this.

[allenwb]

see see https://bugs.ecmascript.org/show_bug.cgi?id=3526

The spec. originally (or at least at one time, read the whole bug thread) had the equivalent to @zenparsing’s proposed change. That was replaced with the current behavior as a fix for Comment #8. This change added both steps 5.b.ii.5.a&b (using the current draft steps) and 5.c.vii.1&2.

But it appears that the 5.b.ii.5.a&b change may have been unnecessary as Comment #8 is about invoking return rather than throw on the outer iterator. Basically that says that the current V8&FF semantics make the most sense and @zenparsing's fix is appropriate. The Edge semantics seem wrong as the exception has already been handle by the inner catch.

But this is all pretty subtle stuff, particularly when you get finally blocks involved. I recall a discussion on either es-discuss or in TC39 meeting notes where the conclusion was that totally transparent delegation via yield* (as originally envisioned) was impossible because of issues related to things like this. I haven't found those notes yet but it would be nice to review them to see if they contain anything that relates to this.

[bterlson]

@zenparsing's fix seems good. The old fix to the return path (5.c.vii. 1&2) seems correct. With this fix in place, IIUC, yield* always propagates errors and only propagates returns when .return is called on the outer generator, and otherwise the value is a normal completion with the inner generator's return value.

[bterlson]

@zenparsing's fix seems good. The old fix to the return path (5.c.vii. 1&2) seems correct. With this fix in place, IIUC, yield* always propagates errors and only propagates returns when .return is called on the outer generator, and otherwise the value is a normal completion with the inner generator's return value.

[bterlson]

Unless anyone objects (even weakly) I'll go ahead and apply @zenparsing's fix here (which is what implementations do anyway, other than Chakra which is bugged in a different way, see Microsoft/ChakraCore#137).

[bterlson]

Unless anyone objects (even weakly) I'll go ahead and apply @zenparsing's fix here (which is what implementations do anyway, other than Chakra which is bugged in a different way, see Microsoft/ChakraCore#137).

[littledan]

Sounds good to me

[littledan]

Sounds good to me