Storing tracebacks

[George Sakkis]

On May 29, 1:21 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Tue, 29 May 2007 13:51:09 -0300, George Sakkis
> <george.sak... at gmail.com> escribió:
>
> > The traceback module is handy if you want a text representation of the
> > traceback, not the actual traceback. The reason I want to store the
> > actual traceback is to make the exception transparent to the user,
> > i.e. not be able to tell whether the exception was thrown in the
> > current stack frame or in another thread or even process.
> > Unfortunately tracebacks are not pickleable, otherwise I could just
> > pickle them in process() and unpickle them in result().
>
> 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 ?

George