Storing tracebacks

[Gabriel Genellina]

En Tue, 29 May 2007 15:13:33 -0300, George Sakkis  
<george.sakkis at gmail.com> escribió:

> On May 29, 1:21 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> 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