Andy Wingo wrote:
>> As a matter of design policy we rarely, if ever, just drop exceptions.
>
> I probably didn't explain myself completely; apologies.  I meant that
> the mechanism of iter.return() should be implemented by throwing an
> exception (i.e., as if by "iter.throw(new StopIteration)") instead of
> "returning" from the yield point.

Hi Andy,

You may have missed it, but way back in ES4 days, Igor Bukanov and I 
implemented generators based in large part on Python 2.5 in 
SpiderMonkey. We didn't implement GeneratorExit (the exception thrown by 
close at the generator parked in a yield). Instead, Igor argued here and 
on python-dev in favor of forcing a return, and Phillip J. Eby among 
other Python leaders agreed that was better (and perhaps Python would 
move that way in the future).

https://mail.python.org/pipermail/python-dev/2006-August/068429.html

is the head of the python-dev thread.

https://mail.mozilla.org/pipermail/es-discuss/2006-December/000297.html

is the oldest es-discuss hit I can find quickly.

I think aesthetics are better, but _de gustibus_. Beyond the ugliness of 
implicit throw and a magic singleton per realm to throw, not polluting 
catch clauses in the field with a new exception object seems like a 
substantive win to me, as to Igor, Phillip , et al. People do write 
unguarded catches and make assumptions about what they caught. They 
shouldn't, but they do.

So I see some risk in adding a new exception and built-in throw. The 
risk of catching a return seems strictly much-less-than, at a glance.

/be

Andy Wingo wrote:

> I probably didn't explain myself completely; apologies.  I meant that
> the mechanism of `iter.return()` should be implemented by throwing an
> exception (i.e., as if by `iter.throw(new StopIteration)`) instead of
> "returning" from the yield point.

You may have missed it, but way back in ES4 days, Igor Bukanov and I 
implemented generators based in large part on Python 2.5 in 
SpiderMonkey. We didn't implement GeneratorExit (the exception thrown by 
close at the generator parked in a yield). Instead, Igor argued here and 
on python-dev in favor of forcing a return, and Phillip J. Eby among 
other Python leaders agreed that was better (and perhaps Python would 
move that way in the future).

https://mail.python.org/pipermail/python-dev/2006-August/068429.html

is the head of the python-dev thread.

https://mail.mozilla.org/pipermail/es-discuss/2006-December/000297.html

is the oldest es-discuss hit I can find quickly.

I think aesthetics are better, but _de gustibus_. Beyond the ugliness of 
implicit throw and a magic singleton per realm to throw, not polluting 
catch clauses in the field with a new exception object seems like a 
substantive win to me, as to Igor, Phillip , et al. People do write 
unguarded catches and make assumptions about what they caught. They 
shouldn't, but they do.

So I see some risk in adding a new exception and built-in throw. The 
risk of catching a return seems strictly much-less-than, at a glance.