“外包”异常处理给装修人员

Question

许多尝试/除/最后-子句不仅“丑化”了我的代码，而且我发现自己经常在类似的任务中使用相同的异常处理。所以我在考虑把他们“外包”到一个.装饰师。

因为我肯定不是第一个得出这个结论的人，所以我在谷歌上搜索并发现了这个- imho -巧妙的食谱，它增加了处理多个异常的可能性。

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

1. 在异常处理中使用装饰模式是虚假的，还是一直以来我都错过了？请指点我！什么是陷阱？
2. 是否甚至有一个包/模块支持以合理的方式创建这样的异常处理？

Answer 1

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

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

def MyInt(text):
    return int(text)

如果text不能被转换，我们该怎么办？还0？返回None

如果您有许多简单的案例，那么我可以看到一个简单的装饰器是有用的，但是我认为您链接到的菜谱做得太多了:它允许为每个可能的异常激活不同的函数--在这些情况下(几个不同的异常，几个不同的代码路径)，我会推荐一个专用的包装函数。

下面是我对一个简单的装饰方法的看法：

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

Answer 2

基本上，缺点是您不再决定如何在调用上下文中处理异常(只允许异常传播)。在某些情况下，这可能导致责任不分开。

Answer 3

1. Python中的装饰器与Decorator模式不一样，虽然有一些相似之处。你在这里的意思还不完全清楚，但我认为你指的是Python的那个(因此，最好不要使用这个词模式)。
2. Python的装饰器对于异常处理并不那么有用，因为您需要将一些上下文传递给装饰器。也就是说，要么传递全局上下文，要么在外部上下文中隐藏函数定义，这需要，我要说，类似LISP的思维方式。
3. 您可以使用contextmanagers而不是装饰器。我确实为此目的使用过它们。