Python 断言是拐杖吗？ [复制]答案

【问题标题】：Are Python assertions crutches? [duplicate]Python 断言是拐杖吗？ [复制]
【发布时间】：2015-02-28 10:05:28
【问题描述】：

正如Python wiki 中所建议的，断言对

但是，使用断言和使用“if”语句并引发异常之间的界限在哪里？

例如。

def some_domain_operation(user, invoice):
    assert isinstance(user, (User, int))
    # Do something.

对

def some_domain_operation(user, invoice):
    if not isinstance(user, (User, int)):
        raise ValueError()

    # Do something.

我认为使用断言是不可靠的（可能会被用户禁用），所以我不能举一个很好的例子，当使用断言比在raise next 中使用显式“if”更好时。

您对 Pn python 断言有何看法。他们是拐杖吗？

【问题讨论】：

第二个例子是TypeError，而不是ValueError。
我的看法/我被教导的方式是，当您希望应用程序从错误中恢复时使用异常，而断言用于在某些不应该中断的情况下杀死您的程序, 休息。所以一个完美编写的程序仍然可以抛出/捕获异常，但绝不应该使断言失败。
stackoverflow.com/questions/944592/…
帕德莱克·坎宁安，谢谢。

【解决方案1】：

在我看来，if和assert有很大的区别：

assert 之后的表达式从不为真 [1]。如果它是真的，你的程序还不如在那个时候停止执行，因为我们不再知道什么是真的。 [2] 它们只是为查看源代码的开发人员提供调试和文档帮助。

从字面上看，一个断言说“在程序流程的这一点上这是真的。在任何情况下，这个表达式都不会为假”。

因此，assert 应被视为不变量。在正确编写的模块中，不会命中任何assert。如果我们考虑您的情况：

assert isinstance(user, (User, int))

如果禁用此assert 会改变模块的行为，则它不应再是assert，而是引发TypeError。

[1] ... 在一个行为良好、编写正确的程序中。

[2] 你应该永远捕捉AssertionError，除非你需要捕捉AssertionError

【讨论】：