Brendan Eich wrote:
Any exceptions that occur in the generator body prior to the first
yield will be expected at the first call to next().
That would be loc 2, though -- seems to go against what you wrote
earlier.
I stick by this! ;-)
It also is not how generators work in Python or JS1.7+:
Sorry for rehashing something else here, I see your point. If we want
loc 1 (if *you* do ;-), then there could be a pending exception from a
thrower() default parameter. That's where I started, up-thread. But this
is strictly more complicated.
Morever, the opening left brace does not make a scope boundary between
formals and local vars. It doesn't even make a hoisting boundary for
functions:
js> function f(x){ function x(){}; return x; }
js> f(42)
function x(){}
Sorry, C fans (sorry, me!).
/be
Python 2.6.6 (r266:84292, May 28 2011, 19:08:00)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def g():
... raise BaseException('foo')
... yield
...
>>> i = g()
>>> i.next()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in g
BaseException: foo
js> function g(){throw 42; yield}
js> i = g()
({})
js> i.next()
uncaught exception: 42
The exception comes after the first .next() that starts from the
implicit yield point.
The design doesn't work if there's no implicit yield first. The rest
of what's shown above follows from that.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
