目录

• 什么是 assert 断言
• 断言和异常的使用场景
• 使用断言的几个原则
• 建议不使用断言的情况：
• 总结

什么是 assert 断言

Assert statements are a convenient way to insert debugging assertions into a program

断言声明是用于程序调试的一个便捷方式。断言可以看做是一个 debug 工具，Python 的实现也符合这个设计哲学，在 Python 中 assert 语句的执行是依赖于__debug__这个内置变量的，其默认值为True。当__debug__为True时，assert 语句才会被执行。

对于一般的声明，assert expression 等价于

if __debug__:
    if not expression: raise AssertionError

assert 可以同时声明两个 expression，例如 assert expression1, expression2 等价于

if __debug__:
    if not expression1: raise AssertionError(expression2)

如果执行脚本文件时加上-O参数， __debug__则为False

举一个例子，假设我们有一个脚本 testAssert.py，内容为：

print(__debug__)
assert 1 > 2

当使用python assert.py运行时，__debug__会输出 True，assert 1 > 2 语句会抛出 AssertionError 异常。

当使用python -O assert.py运行时，__debug__会输出 False，assert 1 > 2 语句由于没有执行不会报任何异常。

断言和异常的使用场景

先说结论：

检查先验条件使用断言，检查后验条件使用异常

举个例子来说明一下，在开发中我们经常会遇到读取本地文件的场景。我们定义一个 read_file 方法。

def read_file(path):
    assert isinstance(file_path, str)
    ...

read_file 函数要求在开始执行的时候满足一定条件：file_path 必须是 str 类型，这个条件就是先验条件，如果不满足，就不能调用这个函数，如果真的出现了不满足条件的情况，证明代码中出现了 bug，这时候我们就可以使用 assert 语句来对 file_path 的类型进行推断，提醒程序员修改代码，也可以使用 if...raise...语句来实现 assert，但是要繁琐很多。在很多优秀的 Python 项目中都会看到使用 assert 进行先验判断的情况，平时可以多多留意。

read_file 函数在被调用执行后，依然需要满足一定条件，比如 file_path 所指定的文件需要是存在的，并且当前用户有权限读取该文件，这些条件称为后验条件，对于后验条件的检查，我们需要使用异常来处理。

def read_file(file_path):
    assert isinstance(file_path, str)
    if not check_exist(file_path):
        raise FileNotFoundError()
    if not has_privilege(file_path):
        raise PermissionError()

文件不存在和没有权限，这两种情况并不属于代码 bug，是代码逻辑的一部分，上层代码捕获异常后可能会执行其他逻辑，因此我们不能接受这部分代码在生产环境中被忽略，这属于后验条件。并且，相比于 assert 语句只能抛出 AssertionError，使用异常可以抛出更详细的错误，方便上层代码针对不同错误执行不同的逻辑。

使用断言的几个原则

1. 使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别，后者是必然存在的并且是一定要作出处理的。
   
2. 使用断言对函数的参数进行确认。 
3. 在编写函数时，要进行反复的考查，并且自问：“我打算做哪些假定？”一旦确定了的假定，就要使用断言对假定进行检查。
4. 一般教科书都鼓励程序员们进行防错性的程序设计，但要记住这种编程风格会隐瞒错误。当进行防错性编程时，如果“不可能发生”的事情的确发生了，则要使用断言进行报警。
   

断言也可以用于代码测试，用作一个做事毛手毛脚的开发人员的单元测试，只要能你接受当使用-O标志时这个测试什么都不做。我有时也会在代码中用"assert Fasle"来对还没有实现的分支作标记，当然我希望他们失败。如果稍微更细节一些，或许触发NotImplementedError是更好的选择

另一个断言用得好的地方就是检查程序中的不变量。一个不变量是一些你能相信为真的条件，除非一个缺陷导致它变成假。如果有一个缺陷，越早发现越好，因此我们需要对其进行测试，但我们不想因为这些测试而影响代码执行速度。因此采用断言，它能在开发时生效而在产品中失效。

断言也是一个很好的检查点注释。为了替代如*释：

#当我们执行到这里，我们知道n>2 
 
#你可以确保在运行时用以下断言：
 
assert n > 2

建议不使用断言的情况：

• 不要用于测试用户提供的数据，或者那些需要在所有情况下需要改变检查的地方
• 不要用于检查你认为在通常使用中可能失败的地方。断言用于非常特别的失败条件。你的用户绝不看到一个AssertionError，如果看到了，那就是个必须修复的缺陷。
• 特别地不要因为断言只是比一个明确的测试加一个触发异常矮小而使用它。断言不是懒惰的代码编写者的捷径。
• 不要将断言用于公共函数库输入参数的检查，因为你不能控制调用者，并且不能保证它不破坏函数的合约。
• 不要将断言用于你期望修改的任何错误。换句话，你没有任何理由在产品代码捕获一个AssertionError异常。
• 不要太多使用断言，它们使代码变得晦涩难懂。
  

总结