许多 try/except/finally 子句不仅“丑化”了我的代码,而且我发现自己经常对类似任务使用相同的异常处理。所以我正在考虑通过将它们“外包”给......装饰者来减少冗余。
因为我确定不是第一个得出这个结论的人,所以我用 Google 搜索并发现了这个 - 恕我直言 - 巧妙 recipe这增加了处理多个异常的可能性。
但我很惊讶为什么这本身似乎并不是一种广为人知和使用的做法,所以我想知道是否有一个方面我没有考虑?
使用装饰器模式进行异常处理是假的还是我一直都错过了它?请赐教!有哪些陷阱?
是否有一个包/模块支持以合理的方式创建这种异常处理?
最佳答案
在代码本身中保留 try/except/finally block 的最大原因是错误恢复通常是函数的一个组成部分。
例如,如果我们有自己的 int()
函数:
def MyInt(text):
return int(text)
text
不能转换怎么办?返回0
?返回无
?
如果您有许多简单的案例,那么我可以看到一个简单的装饰器很有用,但我认为您链接到的配方试图做太多事情:它允许为每个可能的异常激活不同的功能——在这种情况下作为那些(几个不同的异常(exception),几个不同的代码路径)我会推荐一个专用的包装函数。
这是我对简单装饰器方法的看法:
class ConvertExceptions(object):
func = None
def __init__(self, exceptions, replacement=None):
self.exceptions = exceptions
self.replacement = replacement
def __call__(self, *args, **kwargs):
if self.func is None:
self.func = args[0]
return self
try:
return self.func(*args, **kwargs)
except self.exceptions:
return self.replacement
和示例用法:
@ConvertExceptions(ValueError, 0)
def my_int(value):
return int(value)
print my_int('34') # prints 34
print my_int('one') # prints 0
关于python - "outsourcing"对装饰器的异常处理,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9647021/