[issue3112] implement PEP 3134 exception reporting

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 22 juin 2008 à 19:57 +0000, Adam Olsen a écrit :
> That's still O(n).  I'm not so easily convinced it's cheap enough.

O(n) when n will almost never be greater than 5 (and very often equal to
1 or 2), and when the unit is the cost of a pointer dereference plus the
cost of a pointer comparison, still sounds cheap. We could bench it
anyway.

> And for that matter, I'm not convinced it's correct.  The inner
> exception's context becomes clobbered when we modify the outer
> exception's traceback.  The inner's context should reference the
> traceback as it was at that point.

Yes, I've just thought about that, it's a bit annoying... We have to
decide what is more annoying: that, or a reference cycle that can delay
deallocation of stuff attached to an exception (including local
variables attached to the tracebacks)?

(just a small note: it's exception objects that are chained, not
tracebacks... we never modify tracebacks at any point)

> This would all be a lot easier if reraising always created a new
> exception.

How do you duplicate an instance of an user-defined exception? Using an
equivalent of copy.deepcopy()? It will probably end up much more
expensive than the above-mentioned O(n) search.

> Can you think of a way to skip that only when we can be
> sure its safe?  Maybe as simple as counting the references to it?

I don't think so, the exception can be referenced in an unknown number
of local variables (themselves potentially referenced by tracebacks).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3112>
_______________________________________