On Tue, Jan 26, 2010 at 11:33:40AM -0600, Shawn Walker wrote: > On 01/25/10 07:38 PM, johan...@sun.com wrote: > >Okay. Here's a webrev that should implement what we discussed earlier > >this afternoon. Due to the variety of different exception cases > >possible and the different clean-ups needed, the wrapper function is a > >bit more complicated than a simple try/finally, but it seems to work. > > > > http://cr.opensolaris.org/~johansen/webrev-3720-4/ > > I don't believe that the GeneratorExit should be re-raised to the > caller. My understanding was that the GeneratorExit was > intentionally thrown at the generator itself so that it could do > whatever was needed to abort and handle it without further > assistance. > > Was there a specific reasoning behind doing so instead of just > issuing a "return" or "pass"?
According to the documentation, this would be the correct way to handle the exception. I've verified that calling close() on the generator and re-raising GeneratorExit doesn't leak the exception out to other levels. http://docs.python.org/reference/expressions.html generator.close() Raises a GeneratorExit at the point where the generator function was paused. If the generator function then raises StopIteration (by exiting normally, or due to already being closed) or GeneratorExit (by not catching the exception), close returns to its caller. If the generator yields a value, a RuntimeError is raised. If the generator raises any other exception, it is propagated to the caller. close() does nothing if the generator has already exited due to an exception or normal exit. -j _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
