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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
