我偶然发现了这条线索。这就是我如何处理自定义异常。虽然Fault类有点复杂，但它使用变量参数声明自定义表达异常变得微不足道。

FinalVibration和SingletonVibration都是TypeError的子类，因此将在下面捕获代码。

try:
    <do something>
except TypeError as ex:
    <handler>

这就是Fault不能继承自Exception的原因。允许派生异常从其选择的异常继承。

class Fault:
    """Generic Exception base class. Note not descendant of Exception
Inheriting exceptions override formats"""
    formats = '' # to be overriden in descendant classes

    def __init__(self, *args):
        """Just save args for __str__"""
        self.args = args

    def __str__(self):
        """Use formats declared in descendant classes, and saved args to build exception text"""
        return self.formats.format(*self.args)

class TypeFault(Fault, TypeError):
    """Helper class mixing Fault and TypeError"""

class FinalViolation(TypeFault):
    """Custom exception raised if inheriting from 'final' class"""
    formats = "type {} is not an acceptable base type. It cannot be inherited from."

class SingletonViolation(TypeFault):     
    """Custom exception raised if instancing 'singleton' class a second time"""
    formats = "type {} is a singleton. It can only be instanced once."

FinalViolation，SingletonViolation不幸只接受1个参数。

但是可以很容易地创建多参数错误，例如。

class VesselLoadingError(Fault, BufferError):
    formats = "My {} is full of {}."

raise VesselLoadingError('hovercraft', 'eels')

__main__.船只装载错误：我的气垫船上满是鳗鱼。

使用现代Python异常，您不需要滥用.message或重写__str__（）或__repr_（）或其中任何一个。如果在引发异常时只需要一条信息性消息，请执行以下操作：

class MyException(Exception):
    pass

raise MyException("My hovercraft is full of eels")

这将以MyException结尾：我的气垫船上满是鳗鱼。

如果希望从异常中获得更多的灵活性，可以传递字典作为参数：

raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})

然而，在except块中获取这些细节有点复杂。详细信息存储在args属性中，该属性是一个列表。你需要这样做：

try:
    raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
except MyException as e:
    details = e.args[0]
    print(details["animal"])

仍然可以将多个项传递给异常，并通过元组索引访问它们，但这是非常不鼓励的（甚至在不久前还打算弃用）。如果您确实需要一条以上的信息，并且上面的方法对您来说还不够，那么您应该按照教程中的描述对Exception进行子类化。

class MyError(Exception):
    def __init__(self, message, animal):
        self.message = message
        self.animal = animal
    def __str__(self):
        return self.message

不，不禁止“消息”。它刚刚被弃用。您的应用程序可以使用message正常工作。当然，您可能希望消除弃用错误。

当您为应用程序创建自定义的Exception类时，其中许多类不仅仅是从Exception派生的，而是从其他类派生的，比如ValueError或类似的类。然后你必须适应他们对变量的使用。

如果应用程序中有许多异常，通常最好为所有异常设置一个通用的自定义基类，这样模块的用户就可以

try:
    ...
except NelsonsExceptions:
    ...

在这种情况下，您可以在那里执行所需的__init__和__str__，因此不必对每个异常重复执行。但是，简单地调用消息变量而不是消息就行了。

在任何情况下，您只需要__init__或__str__，如果您执行了与Exception本身不同的操作。因为如果你不赞成，你就需要两者，否则你会得到一个错误。这不是每个类需要的大量额外代码。

要正确定义自己的异常，您应该遵循以下几个最佳实践：

定义从Exception继承的基类。这将允许轻松捕捉与项目相关的任何异常：类MyProjectError（异常）：“”“MyProject异常的基类。”“”在单独的模块中组织异常类（例如exceptions.py）通常是一个好主意。要创建特定异常，请将基本异常类子类化。类CustomError（MyProjectError）：“”“MyProject的自定义异常类。”“”您还可以子类化自定义异常类以创建层次结构。若要向自定义异常添加对额外参数的支持，请使用可变数量的参数定义__init__（）方法。调用基类的__init__（），向其传递任何位置参数（请记住BaseException/Exception需要任意数量的位置参数）。为实例存储额外参数，例如：类CustomError（MyProjectError）：定义__init__（self，*args，**kwargs）：super（）__init__（*参数）self.fo=kwargs.get（'fo'）要使用额外的参数引发此类异常，可以使用：raise CustomError（“发生了一些错误”，foo='fo'）

这种设计遵循Liskov替换原则，因为您可以用派生异常类的实例替换基本异常类的一个实例。此外，它还允许您使用与父类相同的参数创建派生类的实例。

请参阅一篇非常好的文章“Python异常的权威指南”。基本原则是：

始终继承自（至少）异常。始终调用BaseException__init__只有一个参数。构建库时，定义从Exception继承的基类。提供有关错误的详细信息。在有意义时从内置异常类型继承。

还有关于组织（在模块中）和包装异常的信息，我建议阅读该指南。

“在现代Python中声明自定义异常的正确方法是什么？”

这很好，除非您的异常确实是一种更具体的异常：

class MyException(Exception):
    pass

或者更好（也许完美），而不是传递一个docstring：

class MyException(Exception):
    """Raise for my specific kind of exception"""

子类化异常子类

从文档中

例外所有内置的、非系统退出的异常都是从该类派生的。所有用户定义的异常也应由此派生班

这意味着，如果您的异常是一种更具体的异常类型，请将该异常子类化，而不是泛型异常（结果将是您仍然按照文档的建议从异常派生）。此外，您至少可以提供一个docstring（不必强制使用pass关键字）：

class MyAppValueError(ValueError):
    '''Raise when my specific value is wrong'''

使用自定义__init__设置您自己创建的属性。避免将dict作为位置参数传递，代码的未来用户将感谢您。如果使用不推荐的消息属性，则自行分配该属性将避免出现不推荐的警告：

class MyAppValueError(ValueError):
    '''Raise when a specific subset of values in context of app is wrong'''
    def __init__(self, message, foo, *args):
        self.message = message # without this you may get DeprecationWarning
        # Special attribute you desire with your Error, 
        # perhaps the value that caused the error?:
        self.foo = foo         
        # allow users initialize misc. arguments as any other builtin Error
        super(MyAppValueError, self).__init__(message, foo, *args) 

真的没有必要编写自己的__str__或__repr_。内置的非常好，您的合作继承确保您使用它们。

对顶级答案的批评

也许我错过了这个问题，但为什么不呢

class MyException(Exception):
    pass

同样，上面提到的问题是，为了捕获异常，您必须对其进行专门命名（如果在其他地方创建，则将其导入）或捕获异常（但您可能没有准备好处理所有类型的异常，您应该只捕获准备好处理的异常）。与下面的批评类似，但另外，这不是通过super进行初始化的方法，如果访问message属性，您将收到DeprecationWarning：

编辑：要覆盖某些内容（或传递额外的参数），请执行以下操作：

class ValidationError(Exception):
    def __init__(self, message, errors):

        # Call the base class constructor with the parameters it needs
        super(ValidationError, self).__init__(message)

        # Now for your custom code...
        self.errors = errors

这样，您就可以将错误消息的dict传递给第二个参数，然后使用e.errors进行处理

它还需要正好传入两个参数（除了self）。这是一个有趣的限制，未来的用户可能不会理解。

直接地说，这违反了利斯科夫的可替代性。

我将演示这两个错误：

>>> ValidationError('foo', 'bar', 'baz').message

Traceback (most recent call last):
  File "<pyshell#10>", line 1, in <module>
    ValidationError('foo', 'bar', 'baz').message
TypeError: __init__() takes exactly 3 arguments (4 given)

>>> ValidationError('foo', 'bar').message
__main__:1: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
'foo'

对比：

>>> MyAppValueError('foo', 'FOO', 'bar').message
'foo'