Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le dimanche 22 juin 2008 à 17:17 +0000, Adam Olsen a écrit : > I meant only that trivial cycles should be detected. However, I > hadn't read your patch, so I didn't realize you already knew of a way > to create a non-trivial cycle. > > This has placed a niggling doubt in my mind about chaining the > exceptions, rather than the tracebacks. Hrm.
Chaining the tracebacks rather than the exceptions loses important information: what is the nature of the exception which is the cause or context of the current exception? It is improbable to create such a cycle involuntarily, it means you raise an old exception in replacement of a newer one caused by the older, which I think is quite contorted. It is also quite easy to avoid creating the cycle, simply by re-raising outside of any except handler. > Ahh, harmless then, but to what benefit? I don't know, I've never used that API, I just proposed returning that error code since it is computed inside the function anyway. But let's drop that proposal. Same for PyErr_DisplaySingle if nobody cares. > Wouldn't the traceback > module be better suited to any possible error reporting? I suppose built-in reporting is needed when reporting a grave error such as a MemoryError (C code can avoid doing any memory allocations), or an error that occurred during startup before any pure Python modules could be initialized (how would you report a syntax error in the traceback module itself?). But application code should use the traceback module rather than try to access the C API. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3112> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
