En Tue, 29 May 2007 15:13:33 -0300, George Sakkis <[EMAIL PROTECTED]> escribió:
> On May 29, 1:21 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> > wrote: >> A traceback contains a linked list of frames, each with its own globals >> and locals and lot of context info. >> I'm not sure that moving a traceback across processes has any sense; a >> textual representation should be enough, as t.b. are usually a debugging >> aid and not supposed to reach the final user. > > The final user in this case is another programmer that uses a library, > not some random guy using an application, so he certainly would be > interested in seeing the traceback. I agree that the traceback is > useful for debugging and the text representation would be enough if, > for example, it was stored as an attribute in the Exception object and > then used automatically by the runtime system (instead of calling > sys.exc_info()). Of course nobody stops me from sticking > traceback.format_tb() as an attribute in the Exception object and then > have the client access it explicitly, something like: > > try: r = job.result() > except Exception, ex: > print ex.traceback > > The problem with this is that it's not transparent any more. The > client must know that the originally raised object has been modified > (or wrapped), sys.exc_info() doesn't work as expected, etc. It's not a > show stopper by any means, but it would be convenient if there was a > standardized optional "traceback" attribute that the runtime looks for > and treats as the 3rd item of sys.exc_info() (otherwise it falls back > to the current behavior). Would this be a reasonable feature request ? Already requested - see PEP 344 and 3110 for changes on exception handling and tracebacks (in Python 3.0 at least; I'm unsure of the PEP344 status on the 2.X series) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
