En Fri, 15 May 2009 15:09:45 -0300, Edd <e...@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
--
http://mail.python.org/mailman/listinfo/python-list
