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