Appending traceback from exception in child thread

[Gabriel Genellina]

En Fri, 15 May 2009 15:09:45 -0300, Edd <edd at nunswithguns.net> escribió:

> As the comment on the last line indicates, looking at the .value() of
> a Future may give the return value of the associated task, or it may
> also propagate an exception that was raised in a child thread.
>
> Inside the implementation I store caught exceptions with code that
> looks something like:
>
>     try:
>         self.return_value = self.task()
>     except:
>         self.exception = sys.exc_info()[1]
>
> The problem I have is that when an exception is propagated in to the
> parent thread by re-raising it, the part of the traceback from the
> child thread is lost. So if the program dies due to such an exception,
> I can't see what caused it by examining the printed traceback.
>
> To solve this problem, I could of course grab the traceback in the
> child thread and create some kind of custom exception that stashes the
> trace inside. This could then be caught on the fringes of my code in
> order to combine the tracebacks of parent and child together before
> printing it. But I was wondering if there might be a nicer way that
> keeps the original exception object. Perhaps something akin to gluing
> the tracebacks together at the point where the exception is re-raised?

You could use the 3-argument form of the raise statement:
http://docs.python.org/reference/simple_stmts.html#the-raise-statement

There is a problem: remember that the traceback object keeps a reference  
to all previous frames -- that means, all local variables along the whole  
stack of called functions are kept alive until you delete the traceback  
object. And depending on your application, that might involve thousand of  
objects "artificially" alive for an undeterminate period of time...

It it's just for logging/debugging and you don't require access to the  
"live" objects, using a custom attribute in the exception object to store  
a list of strings (like the one traceback.extract_tb builds) may be a  
better idea.

-- 
Gabriel Genellina