Message68565
| Author |
pitrou |
| Recipients |
Rhamphoryncus, benjamin.peterson, gvanrossum, pitrou |
| Date |
2008年06月22日.14:07:10 |
| SpamBayes Score |
0.0047338237 |
| Marked as misclassified |
No |
| Message-id |
<1214143625.6056.8.camel@fsol> |
| In-reply-to |
<1214118298.94.0.429406658597.issue3112@psf.upfronthosting.co.za> |
| Content |
Le dimanche 22 juin 2008 à 07:04 +0000, Adam Olsen a écrit :
> Adam Olsen <rhamph@gmail.com> added the comment:
>
> * cause/context cycles should be avoided. Naive traceback printing
> could become confused, and I can't think of any accidental way to
> provoke it (besides the problem mentioned here.)
You mean they should be detected when the exception is set? I was afraid
that it may make exception raising slower. Reporting is not performance
sensitive in comparison to exception raising.
(the "problem mentioned here" is already avoided in the patch, but the
detection of other cycles is deferred to exception reporting for the
reason given above)
> * PyErr_Display is used by PyErr_Print, and it must end up with no
> active exception. Additionally, third party code may depend on this
> semantic. Maybe PyErr_DisplayEx?
I was not proposing to change the exception swallowing semantics, just
to add a return value indicating if any errors had occurred while
displaying the exception. |
|