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:[email protected]] On Behalf Of Allen Wirfs-Brock Sent: Monday, February 2, 2015 12:09 To: Jason Orendorff Cc: es-discuss list; [email protected]; 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 <[email protected]<mailto:[email protected]>> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
