Python：将预期的异常存储在函数属性中

Question

将函数的预期异常存储为函数本身的属性是否为pythonic？ 或只是一个恶心的坏习惯。

像这样

class MyCoolError(Exception):
    pass

def function(*args):
    """
    :raises: MyCoolError

    """
    # do something here
    if some_condition:
        raise MyCoolError

function.MyCoolError = MyCoolError

还有其他模块

try:
    function(...)
except function.MyCoolError:
    #...

Pro：在我对函数的引用中，也对它可能引发的异常的引用，也不必显式导入。

缺点：我“有”重复异常的名称以将其绑定到函数。 这可以用装饰器来完成，但这也增加了复杂性。

编辑

我之所以这样做，是因为我以不规则的方式将某些方法附加到某些类上，在这些类中，我认为不值得使用mixin。 我们称其为“量身定制的功能”。 例如，让我们说：

• Class A使用方法fn1和fn2
• Class B使用方法fn2和fn3
• Class C使用fn4 ...
• 像这样大约15个班级。

因此，当我调用obj_a.fn2() ，我必须显式导入它可能引发的异常（它不在类A，B或C所在的模块中，而是在共享方法所在的另一类中）...我认为这有点烦人。 Appart从此开始，我正在努力的项目中的标准样式迫使每行编写一个导入，因此它变得非常冗长。

在某些代码中，我看到了异常存储为类属性，并且发现它非常有用，例如：

try:
    obj.fn()
except obj.MyCoolError:
    ....

Answer 1

我认为这不是Pythonic。 我还认为，与仅将异常与函数一起导入的标准方法相比，它没有提供太多优势。

有一个原因（除了帮助解释器外），为什么Python程序使用import语句来说明其代码的来源； 它有助于查找正在使用的设施的代码（例如，本例中的异常）。

整个想法都有异常声明的味道，因为在C ++中是可能的，而在Java中则是部分强制的。 语言律师之间一直在讨论这是一个好主意还是一个坏主意，在Python世界中，设计人员决定反对它，因此这不是Pythonic。

它还提出了很多其他问题。 如果您的函数A使用另一个函数B，然后又对其进行了更改以使其可以引发异常（在Python中是有效的东西），将会发生什么。 您是否愿意先更改函数A使其反映（或在A中捕获）？ 您想在哪里画线—使用int(text)将字符串转换为int的原因足以“声明”可以抛出ValueError ？

总而言之，我认为这不是Pythonic，不是。