Domenic Denicola (2015-02-02T17:11:56.000Z)
I don’t think we should be assuming that an abnormal completion should run anything like the same logic as a normal completion. If I understand correctly, that’s what any proposal to fall back to “close” does.

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Allen Wirfs-Brock
Sent: Monday, February 2, 2015 12:09
To: Jason Orendorff
Cc: es-discuss list; marc.nieper+bugzilla at gmail.com; Erik Arvidsson
Subject: Re: a weird yield* edge case


On Feb 2, 2015, at 7:26 AM, Jason Orendorff wrote:


On Sat, Jan 31, 2015 at 10:56 AM, Erik Arvidsson <erik.arvidsson at gmail.com<mailto:erik.arvidsson at gmail.com>> wrote:

Another option would be to throw. Then the caller can tell that they did something that was not expected by the inner iterator.

I agree. In fact, isn't this required by transparency?

Inner().throw() in this situation would throw a TypeError (since there's no such method). So wrapper().throw() should throw a TypeError.

Except that a consumer (such as for-of) is expected to check for the existence of 'throw' before trying to invoke it.  That's really where the transparency is lost in this case.

But I agree that throwing to indicate a "protocol violation" seems like a good approach.  but it could mean that Inner doesn't get properly "closed".  How how about this variation:

2a) An TypeError exception is thrown, but first 'close' (if it is present) is invoked on the yield* target iterator.

That would seem to both satisfy the 'close' contract (a consumer (in this case yield*) calls it if is terminating its use of an iterator before the "done" state is reached) and produces an exception to the wrapper consumer for the "throw" protocol violation.

Allen










-j

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150202/e93cdfa7/attachment.html>
d at domenic.me (2015-02-13T23:48:33.716Z)
I don’t think we should be assuming that an abnormal completion should run anything like the same logic as a normal completion. If I understand correctly, that’s what any proposal to fall back to “close” does.