[Python-Dev] with_traceback

glyph at divmod.com glyph at divmod.com
Wed Feb 28 06:49:23 CET 2007


On Tue, 27 Feb 2007 13:37:21 +1300, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

>I don't like that answer. I can think of legitimate
>reasons for wanting to pre-create exceptions, e.g. if
>I'm intending to raise and catch a particular exception
>frequently and I don't want the overhead of creating
>a new instance each time.

This seems like kind of a strange micro-optimization to have an impact on a language change discussion.  Wouldn't it be better just to optimize instance creation overhead?  Or modify __new__ on your particular heavily-optimized exception to have a free-list, so it can be both correct (you can still mutate exceptions) and efficient (you'll only get a new exception object if you really need it).

>For me, this is casting serious doubt on the whole
>idea of attaching the traceback to the exception.

I'm sorry if this has been proposed already in this discussion (I searched around but did not find it), but has anyone thought of adding methods to Exception to handle these edge cases and *not* attempting to interact with the 'raise' keyword at all?  This is a strawman, but:

 except Foo as foo:
   if foo.some_property:
     foo.reraise(modify_stack=False)

This would make the internal implementation details less important, since the 'raise' keyword machinery will have to respect some internal state of the exception object in either case, but the precise thing being raised need not be the result of the method, nor the exception itself.


More information about the Python-Dev mailing list