This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Rhamphoryncus
Recipients Rhamphoryncus, benjamin.peterson, gvanrossum, pitrou
Date 2008-06-22.19:57:50
SpamBayes Score 0.011476137
Marked as misclassified No
Message-id <aac2c7cb0806221257j466a4f6fmb3c9a43a2db54f8f@mail.gmail.com>
In-reply-to <1214164129.6056.63.camel@fsol>
Content
On Sun, Jun 22, 2008 at 1:48 PM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Le dimanche 22 juin 2008 à 19:23 +0000, Adam Olsen a écrit :
>> For this behaviour, this is the most natural way to write it.
>> Conceptually, there shouldn't be a cycle
>
> I agree your example is not far-fetched. How about avoiding cycles for
> implicit chaining, and letting users shoot themselves in the foot with
> explicit recursive chaining if they want? Detection would be cheap
> enough, just a simple loop without any memory allocation.

That's still O(n).  I'm not so easily convinced it's cheap enough.

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.

This would all be a lot easier if reraising always created a new
exception.  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?
History
Date User Action Args
2008-06-22 19:57:53Rhamphoryncussetspambayes_score: 0.0114761 -> 0.011476137
recipients: + Rhamphoryncus, gvanrossum, pitrou, benjamin.peterson
2008-06-22 19:57:52Rhamphoryncuslinkissue3112 messages
2008-06-22 19:57:50Rhamphoryncuscreate