python - "outsourcing"装饰器的异常处理

关闭。这个问题是 opinion-based 。它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文来回答。

2年前关闭。



Improve this question




许多 try/except/finally 子句不仅“丑化”了我的代码，而且我发现自己经常对类似的任务使用相同的异常处理。所以我正在考虑通过将它们“外包”给......装饰器来减少冗余。

因为我确定不是第一个得出这个结论的人，所以我用谷歌搜索并发现了这个 - 恕我直言 - 巧妙的 recipe 增加了处理多个异常的可能性。

但是我很惊讶为什么这本身似乎并不是一个广为人知和使用的实践，所以我想知道是否有我没有考虑的方面？

使用装饰器模式进行异常处理是假的还是我一直想念它？请赐教!有哪些陷阱？

甚至可能有一个包/模块支持以合理的方式创建这种异常处理吗？

最佳答案

在代码本身中保留 try/except/finally 块的最大原因是错误恢复通常是函数的一个组成部分。

例如，如果我们有自己的 int() 函数:

def MyInt(text):
    return int(text)

text无法转换怎么办？返回 0 ？返回 None ？

如果您有许多简单的情况，那么我可以看到一个简单的装饰器很有用，但我认为您链接到的配方尝试做的太多:它允许为每个可能的异常激活不同的功能 - 在这种情况下(几个不同的异常(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/