使用concurrent.futures的示例(2.7的backport):
import concurrent.futures # line 01
def f(x): # line 02
return x * x # line 03
data = [1, 2, 3, None, 5] # line 04
with concurrent.futures.ThreadPoolExecutor(len(data)) as executor: # line 05
futures = [executor.submit(f, n) for n in data] # line 06
for future in futures: # line 07
print(future.result()) # line 08
输出:
1
4
9
Traceback (most recent call last):
File "C:\test.py", line 8, in <module>
print future.result() # line 08
File "C:\dev\Python27\lib\site-packages\futures-2.1.4-py2.7.egg\concurrent\futures\_base.py", line 397, in result
return self.__get_result()
File "C:\dev\Python27\lib\site-packages\futures-2.1.4-py2.7.egg\concurrent\futures\_base.py", line 356, in __get_result
raise self._exception
TypeError: unsupported operand type(s) for *: 'NoneType' and 'NoneType'
字符串"...\_base.py", line 356, in __get_result"
不是我期望看到的端点。是否有可能获得抛出异常的实线?类似的东西:
File "C:\test.py", line 3, in f
return x * x # line 03
在这种情况下,Python3似乎显示正确的行号。为什么不能python2.7?有没有解决办法?
答案 0 :(得分:21)
我遇到了同样的情况,我真的需要对引发的异常进行回溯。
我能够开发这种解决方法,其中包括使用以下的子类
ThreadPoolExecutor
。
import sys
import traceback
from concurrent.futures import ThreadPoolExecutor
class ThreadPoolExecutorStackTraced(ThreadPoolExecutor):
def submit(self, fn, *args, **kwargs):
"""Submits the wrapped function instead of `fn`"""
return super(ThreadPoolExecutorStackTraced, self).submit(
self._function_wrapper, fn, *args, **kwargs)
def _function_wrapper(self, fn, *args, **kwargs):
"""Wraps `fn` in order to preserve the traceback of any kind of
raised exception
"""
try:
return fn(*args, **kwargs)
except Exception:
raise sys.exc_info()[0](traceback.format_exc()) # Creates an
# exception of the
# same type with the
# traceback as
# message
如果您使用此子类并运行以下代码段:
def f(x):
return x * x
data = [1, 2, 3, None, 5]
with ThreadPoolExecutorStackTraced(max_workers=len(data)) as executor:
futures = [executor.submit(f, n) for n in data]
for future in futures:
try:
print future.result()
except TypeError as e:
print e
输出类似于:
1
4
9
Traceback (most recent call last):
File "future_traceback.py", line 17, in _function_wrapper
return fn(*args, **kwargs)
File "future_traceback.py", line 24, in f
return x * x
TypeError: unsupported operand type(s) for *: 'NoneType' and 'NoneType'
25
问题在于sys.exc_info()
库使用futures
。来自
文档:
此函数返回三个值的元组,这些值提供有关异常的信息 目前正在处理中。 [...] 如果堆栈中的任何地方都没有处理异常,则包含三个None值的元组是 回。否则,返回的值是(type,value,traceback)。他们的意思是:类型得到 正在处理的异常的异常类型(类对象);值得到例外 参数(其关联值或要引发的第二个参数,它始终是一个类实例 如果异常类型是类对象); traceback获取一个封装了的回溯对象 在最初发生异常的位置调用堆栈。
现在,如果你看一下futures
的源代码,你可以自己看看为什么回溯是
丢失:当异常引发并且仅将其设置为Future
对象时
sys.exc_info()[1]
已通过。参见:
https://code.google.com/p/pythonfutures/source/browse/concurrent/futures/thread.py(L:63) https://code.google.com/p/pythonfutures/source/browse/concurrent/futures/_base.py(L:356)
因此,为了避免丢失回溯,您必须将其保存在某处。我的解决方法是包装
提交到包装器的函数,其唯一的任务是捕获各种异常和
引发相同类型的异常,其消息是回溯。通过这样做,当一个
异常被提出它被包装器捕获并重新加载,然后sys.exc_info()[1]
被分配给Future
对象的例外,回溯不会丢失。
答案 1 :(得分:10)
我认为原始异常回溯在ThreadPoolExecutor代码中丢失了。它存储异常,然后再重新引发它。这是一个解决方案。您可以使用 traceback 模块将原始异常消息和函数 f 中的回溯存储到字符串中。然后使用此错误消息引发异常,该消息现在包含 f 的行号等。运行 f 的代码可以包含在 try ... 除块之外,该块捕获从ThreadPoolExecutor引发的异常,并打印消息,其中包含原始追溯。
以下代码适合我。我认为这个解决方案有点hacky,并且希望能够恢复原始的追溯,但我不确定这是否可行。
import concurrent.futures
import sys,traceback
def f(x):
try:
return x * x
except Exception, e:
tracebackString = traceback.format_exc(e)
raise StandardError, "\n\nError occurred. Original traceback is\n%s\n" %(tracebackString)
data = [1, 2, 3, None, 5] # line 10
with concurrent.futures.ThreadPoolExecutor(len(data)) as executor: # line 12
try:
futures = [executor.submit(f, n) for n in data] # line 13
for future in futures: # line 14
print(future.result()) # line 15
except StandardError, e:
print "\n"
print e.message
print "\n"
这在python2.7中提供了以下输出:
1
4
9
Error occurred. Original traceback is
Traceback (most recent call last):
File "thread.py", line 8, in f
return x * x
TypeError: unsupported operand type(s) for *: 'NoneType' and 'NoneType'
原始代码在Python 3而不是2.7中运行时提供正确位置的原因是在Python 3中异常将回溯作为属性进行,并且在重新引发异常时,回溯是扩展而不是替换。下面的例子说明了这一点:
def A():
raise BaseException("Fish")
def B():
try:
A()
except BaseException as e:
raise e
B()
我在 python 2.7 和 python 3.1 中运行了这个。在2.7中,输出如下:
Traceback (most recent call last):
File "exceptions.py", line 11, in <module>
B()
File "exceptions.py", line 9, in B
raise e
BaseException: Fish
即。最初从 A 抛出异常的事实不会记录在最终输出中。当我使用 python 3.1 运行时,我得到了这个:
Traceback (most recent call last):
File "exceptions.py", line 11, in <module>
B()
File "exceptions.py", line 9, in B
raise e
File "exceptions.py", line 7, in B
A()
File "exceptions.py", line 3, in A
raise BaseException("Fish")
BaseException: Fish
哪个更好。如果我在 B 的except块中仅使用raise e
替换raise
,则 python2.7 会提供完整的回溯。我的猜测是,当将此模块反向移植到 python2.7 时,异常传播的差异被忽略了。
答案 2 :(得分:3)
从第一个答案中汲取灵感,这里是装饰者:
import functools
import traceback
def reraise_with_stack(func):
@functools.wraps(func)
def wrapped(*args, **kwargs):
try:
return func(*args, **kwargs)
except Exception as e:
traceback_str = traceback.format_exc(e)
raise StandardError("Error occurred. Original traceback "
"is\n%s\n" % traceback_str)
return wrapped
只需在执行的函数上应用装饰器:
@reraise_with_stack
def f():
pass