assert的使用和异常的引发都与通信有关。

Assertions are statements about the correctness of code addressed at developers: An assertion in the code informs readers of the code about conditions that have to be fulfilled for the code being correct. An assertion that fails at run-time informs developers that there is a defect in the code that needs fixing. Exceptions are indications about non-typical situations that can occur at run-time but can not be resolved by the code at hand, addressed at the calling code to be handled there. The occurence of an exception does not indicate that there is a bug in the code.

最佳实践

因此，如果您将运行时发生的特定情况视为您想要通知开发人员的错误(“嗨，开发人员，这种情况表明某处存在错误，请修复代码。”)，那么请使用断言。如果断言检查代码的输入参数，当输入参数违反条件时，您通常应该在文档中添加代码具有“未定义行为”。

相反，如果这种情况的出现并不是您眼中的错误，而是您认为应该由客户端代码处理的(可能很少，但可能)情况，则引发异常。引发哪种异常的情况应该是相应代码文档的一部分。

有没有演出[…]使用assert时的问题

断言的计算需要一些时间。但是，它们可以在编译时被删除。然而，这有一些后果，见下文。

有[…]使用assert的代码维护问题

Normally assertions improve the maintainability of the code, since they improve readability by making assumptions explicit and during run-time regularly verifying these assumptions. This will also help catching regressions. There is one issue, however, that needs to be kept in mind: Expressions used in assertions should have no side-effects. As mentioned above, assertions can be eliminated at compile time - which means that also the potential side-effects would disappear. This can - unintendedly - change the behaviour of the code.

这是一个悬而未决的问题，我有两个方面想涉及:何时添加断言以及如何编写错误消息。

目的

向初学者解释一下，断言是一种可能引发错误的语句，但您不会捕获它们。他们通常不应该被抚养，但在现实生活中，他们有时还是会被抚养。这是一个严重的情况，代码无法恢复，我们称之为“致命错误”。

其次，它是为了“调试目的”，虽然正确，但听起来非常轻蔑。我更喜欢“声明不变量，它永远不应该被违反”的提法，尽管它对不同的初学者有不同的作用……有些人“只是得到它”，而另一些人要么没有找到它的任何用途，要么取代正常的异常，甚至用它来控制流。

风格

在Python中，assert是语句，而不是函数!(记住assert(False， 'is true')不会引发。但是，先说一下:

何时以及如何编写可选的“错误消息”?

这实际上适用于单元测试框架，它通常有许多专用的方法来执行断言(assertTrue(条件)，assertFalse(条件)，assertEqual(实际的，预期的)等)。它们通常还提供了一种对断言进行评论的方法。

在一次性代码中，您可以不使用错误消息。

在某些情况下，没有什么可以添加到断言:

def垃圾场(东西): 屁 # ...

但除此之外，消息对于与其他程序员(有时是你代码的交互式用户，例如在Ipython/Jupyter等)的交流是有用的。

给他们信息，而不仅仅是泄露内部实现细节。

而不是:

assert meaningless_identifier <= MAGIC_NUMBER_XXX, 'meaningless_identifier is greater than MAGIC_NUMBER_XXX!!!'

写:

assert meaningless_identifier > MAGIC_NUMBER_XXX, 'reactor temperature above critical threshold'

或者甚至:

assert meaningless_identifier > MAGIC_NUMBER_XXX, f'reactor temperature({meaningless_identifier }) above critical threshold ({MAGIC_NUMBER_XXX})'

我知道，我知道——这不是静态断言的情况，但我想指出消息的信息值。

消极还是积极的信息?

这可能是有争议的，但读到这样的东西让我很受伤:

assert a == b, 'a is not equal to b'

这是两个相互矛盾的东西。因此，每当我对代码库产生影响时，我就会通过使用“必须”和“应该”等额外的动词来明确我们想要什么，而不是说我们不想要什么。 断言a == b， 'a必须等于b'

然后，获取AssertionError: a must equal to b也是可读的，并且语句在代码中看起来是合乎逻辑的。此外，您可以在不读取回溯(有时甚至不可用)的情况下从中获得一些信息。

"assert"语句在编译优化时被删除。所以，是的，它们在性能和功能上都有差异。

在编译时请求优化时，当前代码生成器不会为assert语句生成代码。Python 3 Docs

如果您使用assert来实现应用程序功能，然后优化部署到生产环境，那么您将受到“但它在开发中有效”缺陷的困扰。

参见PYTHONOPTIMIZE和-O -OO

英语单词assert在这里的意思是发誓、肯定、宣称。它的意思不是“检查”或“应该是”。这意味着你作为一个程序员要在这里做一个宣誓声明:

# I solemnly swear that here I will tell the truth, the whole truth, 
# and nothing but the truth, under pains and penalties of perjury, so help me FSM
assert answer == 42

如果代码是正确的，除了单事件中断、硬件故障等，任何断言都不会失败。这就是为什么程序对终端用户的行为不能受到影响。特别是，断言即使在异常的编程条件下也不能失败。这种事从来没有发生过。如果发生这种情况，程序员应该为此受到惩罚。

断言应该用于测试不应该发生的情况。目的是在程序状态损坏的情况下尽早崩溃。

异常应该用于可能发生的错误，并且几乎总是应该创建自己的Exception类。

例如，如果您正在编写一个从配置文件读取到dict的函数，那么文件中的不当格式将引发ConfigurationSyntaxError，而您可以断言您不会返回None。

在您的示例中，如果x是通过用户界面或外部源设置的值，则最好使用异常。

如果x只是在同一个程序中由您自己的代码设置的，则使用断言。

如前所述，当您的代码should NOT到达某个点(意味着那里存在错误)时，应该使用断言。在我看来，使用断言最有用的原因可能是不变量/前置/后置条件。在循环或函数的每次迭代的开始或结束时，这些必须为真。

例如，一个递归函数(两个独立的函数，一个处理错误的输入，另一个处理错误的代码，因为它很难与递归区分开来)。如果我忘记写if语句，这将很明显地显示出哪里出了问题。

def SumToN(n):
    if n <= 0:
        raise ValueError, "N must be greater than or equal to 0"
    else:
        return RecursiveSum(n)

def RecursiveSum(n):
    #precondition: n >= 0
    assert(n >= 0)
    if n == 0:
        return 0
    return RecursiveSum(n - 1) + n
    #postcondition: returned sum of 1 to n

这些循环不变量通常可以用断言表示。