On Jan 31, 2015, at 9:50 AM, Kevin Smith 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 like that solution!
> 
> I do as well.  What exactly is thrown - the input to the generator's throw method? 
Don't think so.  The throw method argument is what would have been thrown if the inner iterator actually had a default throw method.

It should probably be a new TypeError, then it's implementation defined text can be something describing the protocol violation.

But this perhaps leads to rethinking what happens when for-of invokes the throw method on its iterator. The plan of record, which the spec. currently reflects, is that if the exception that comes back from the 'throw' method is different from the one that was originally passed in as its argument then the original exception is the one that is propagated out of the for-of.  (There are two possible exceptions that could be propagate in this case, so we have to pick one and drop the other one).

The logic behind that choice, was that the original exception produced by the loop body, is more likely to be the one that the surrounding code was prepared to deal with.  But in the case we are considering, this choice would obscure the fact that the inner protocol violation had occurred.  From a debugging perspective. it  would seem better to propagate the final exception rather than the original exception. That would enable a developer to debug backwards starting from the final exception.  That model seems more likely to make bugs visible and get them fixed.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150131/ad509f94/attachment-0001.html>

Don't think so.  The throw method argument is what would have been thrown if the inner iterator actually had a default throw method.

It should probably be a new TypeError, then it's implementation defined text can be something describing the protocol violation.

But this perhaps leads to rethinking what happens when for-of invokes the throw method on its iterator. The plan of record, which the spec. currently reflects, is that if the exception that comes back from the 'throw' method is different from the one that was originally passed in as its argument then the original exception is the one that is propagated out of the for-of.  (There are two possible exceptions that could be propagate in this case, so we have to pick one and drop the other one).

The logic behind that choice, was that the original exception produced by the loop body, is more likely to be the one that the surrounding code was prepared to deal with.  But in the case we are considering, this choice would obscure the fact that the inner protocol violation had occurred.  From a debugging perspective. it  would seem better to propagate the final exception rather than the original exception. That would enable a developer to debug backwards starting from the final exception.  That model seems more likely to make bugs visible and get them fixed.