使用断言的最佳时机偶尔会被提起,通常是因为有人误用,因此我觉得有必要写一篇文章来阐述一下什么时候应该用断言,为什么应该用,什么时候不该用。

对那些没有意识到用断言的最佳时机的人来说,Python的断言就是检测一个条件,如果条件为真,它什么都不做;反之它触发一个带可选错误信息的AssertionError。如下例所示:

很多人将断言作为当传递了错误的参数值时的一种快速而简便的触发异常的方式。但实际上这是错误的,而且是非常危险的错误,原因有两点。首先,AssertionError通常是在测试函数参数时给出的错误。你不会像下面这样编码:

你应该用TypeError来替代,“断言”解决了错误的异常类型。

但是对断言来说更危险也更纠结的是:如果你执行Python时使用了-O或-OO优化标识,这能够通过编译却从来不会被执行,实际上就是说并不能保证断言会被执行。当恰当地使用了断言,这非常好的,但当不恰当地使用了断言,在使用-O标识执行时它将导致代码被彻底中断。

那么我们什么时候应该使用断言呢?如果没有特别的目的,断言应该用于如下情况:

  • 防御性的编程
  • 运行时对程序逻辑的检测
  • 合约性检查(比如前置条件,后置条件)
  • 程序中的常量
  • 检查文档

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

因为程序员是对于代码正确性表现出的信心不同,因此对于什么时候使用断言的意见各不相同。如果你确信代码是正确的,那么断言没有任何意义,因为它们从不会失败,因此你可以放心地移除它们。如果你确信它们会失败(例如对用户输入的数据的检测),你不敢用断言,这样编译就能通过,但你跳过了你的检查。

在以上两种情况之间的情况就显得特别有趣了,那就是当你相信代码是正确的,但又不是特别确定的时候。或许你忘记了一些奇怪的边角情况(因为我们都是人),在这种情况下,额外的运行时检查将帮助你尽可能早地捕获错误,而不是写了一大堆代码之后。

(这就是为什么使用断言的时机会不同。因为我们对代码正确性的信息不同,对于一个人有用的断言,对于另一个人来说却是无用的运行时测试。)

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

一个关于不变量的例子可能是这样的情况。如果你的函数在开始的时候期望一个打开的数据库连接,并且在函数返回后该数据库连接依然是打开的,这是一个函数的不变量:

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

#当我们执行到这里,我们知道n>2

你可以确保在运行时用以下断言:

断言也是一种防御性的编程形式。你不是在防范当前代码发生错误,而防范由于以后的代码变更发生错误。理想情况下,单元测试应该直到这个作用,但是让我们面对这样一个现实:即使存在单元测试,他们在通常情况下也不是很完备。内建的机器人可能没有工作,但数周以来也没有人注意到它,或者人们在提交代码之前忘记了执行测试。内部检查将是防止错误渗入的另一道防线,尤其对于那些悄悄地失败,但会引起代码功能错误并返回错误结果的情况有效。

假设你有一系列的if...elif代码块,你预先知道变量期望的值:

假设这段代码现在完全正确。但它会一直正确吗?需求变更,代码变更。如果需求变为允许target = w,并关联到run_w_code,那将会发生什么情况?如果我们变更了设置target的代码,但是忘记了改变这个代码块,它就会错误地调用run_z_code(),错误就会发生。对于这段代码最好的方法就是编写一些防御性的检查,这样它的执行,即使在变更以后,要么正确,要么马上失败。

在代码开始添加注释是个好的开端,但是人们都不太喜欢读和更新这些注释,这些注释会很快变得过时。但对于断言,我们可以同时对这块代码编写文档,如果这些断言被违反了,会直接引起一个简单而又直接的失败。

这里的断言同时用于防御性编程和检查文档。我认为这是最优的解决方案:

这诱使开发者去不理代码,移除像value ==c这类不必要的测试,以及RuntimeError的“死代码”。另外,当"unexpected error"错误发生时这个消息将非常窘迫,确实会发生。

合约式设计是断言另一个用得好的地方。在合约式设计中,我们认为函数与其他调用者遵循合约,例如像这样的情况:

“如果你传给我一个非空字符串,我保证返回转换成大写的首字母。”

如果合约被破坏了,不管是被函数本身还是调用者,这都会产生缺陷。我们说这个函数需要有前置条件(对期望的参数的限制)和后置条件(对返回结果的约束)。因此这个函数可能是这样的:

合约式设计的目的是,在一个正确的程序里,所有的前置条件和后置条件都将得到处理。这是断言的经典应用,自(这个想法持续)我们发布无缺陷的程序并且将其放入产品,程序将是正确的并且我们可以放心地移除检查。

这里是我建议不使用断言的情况:

*不要用于测试用户提供的数据,或者那些需要在所有情况下需要改变检查的地方

*不要用于检查你认为在通常使用中可能失败的地方。断言用于非常特别的失败条件。你的用户绝不看到一个AssertionError,如果看到了,那就是个必须修复的缺陷。

*特别地不要因为断言只是比一个明确的测试加一个触发异常矮小而使用它。断言不是懒惰的代码编写者的捷径。

*不要将断言用于公共函数库输入参数的检查,因为你不能控制调用者,并且不能保证它不破坏函数的合约。

*不要将断言用于你期望修改的任何错误。换句话,你没有任何理由在产品代码捕获一个AssertionError异常。

*不要太多使用断言,它们使代码变得晦涩难懂。

Python中何时使用断言 assert的更多相关文章

  1. Eclipse中如何开启断言(Assert),方法有二

    Eclipse中如何开启断言(Assert),方法有二:1.Run -> Run Configurations -> Arguments页签 -> VM arguments文本框中加 ...

  2. Python中何时使用断言

    这个问题是如何在一些场景下使用断言表达式,通常会有人误用它,所以我决定写一篇文章来说明何时使用断言,什么时候不用. 为那些还不清楚它的人,Python的assert是用来检查一个条件,如果它为真,就不 ...

  3. Python中何时使用断言(转)

    原文:http://blog.jobbole.com/76285/ 本文由 伯乐在线 - 贱圣OMG 翻译.未经许可,禁止转载!英文出处:python maillist.欢迎加入翻译小组. 这个问题是 ...

  4. python学习笔记(断言assert)

    最近有了些时间 博主一直在python的unittest框架,这次想看看其他框架 先准备熟悉熟悉 pytest,由于unittest有自己断言方法 而pytest则是使用python自带的 asser ...

  5. python中那个断言assert的优化

    Python Assert 为何不尽如人意# Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛出异常. Copy >>> assert ...

  6. Python中不尽如人意的断言Assertion

    Python Assert 为何不尽如人意 Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛出异常. >>> assert 1 + 1 ...

  7. 【转】Python中不尽如人意的断言Assertion

    原文地址:Python中不尽如人意的断言Assertion Python Assert 为何不尽如人意 Python中的断言用起来非常简单,你可以在assert后面跟上任意判断条件,如果断言失败则会抛 ...

  8. 3.pytest断言assert

    pytest使用的python自带的断言assert关键字,和unittest封装的assert断言不一样 原理:用来测试某个断言条件,如果断言条件为True,则程序将继续正常执行:但如果断言条件为假 ...

  9. python Exception中的raise、assert

    使用raise抛出异常 当程序出现错误,python会自动引发异常,也可以通过raise显式地引发异常.一旦执行了raise语句,raise后面的语句将不能执行. 演示raise用法. try: s ...

随机推荐

  1. mysql sql执行计划

    查看Mysql执行计划 使用navicat查看mysql执行计划: 打开profile分析工具: 查看是否生效:show variable like ‘%profil%’; 查看进程:show pro ...

  2. Keras和tensorflow的区别

    参考: https://blog.csdn.net/zhangbaoanhadoop/article/details/82111056

  3. mysql将视图数据迁移到表中

    #字段必须完全一样 INSERT into table1(所有字段) select * from data.视图

  4. 如何使用Action.Invoke()触发一个Storyboard

    一般在我们的项目中,最好是将Storyboard放在前台,然后设置Storyboard的x:key值,通过我们的TryFindResource来查找到当前的Storyboard来启动Stroyboar ...

  5. Bootstrap之表格、表单应用

    代码: <!DOCTYPE html> <html lang="en" xmlns:th="http://www.w3.org/1999/xhtml&q ...

  6. Linux上面部署java项目

    最近做项目迁移,费了很大周折.总算顺利迁移了.其实一直以为搞不懂单用tomcat是怎么发布项目的.但还是得硬着头皮做. 不过这个是在搭建测试服务器的时候弄的.开始我就直接把程序包丢tomcat里面也能 ...

  7. How to enable usb on vbox

    Device-->Install Guest Addition Shared Folders Settings-->Advanced-->Shared Clipboard--> ...

  8. Spring validator常用注解

    规则: 原版在这里 https://www.cnblogs.com/wjh123/p/8745473.html @AssertFalse Boolean,boolean 验证注解的元素值是false ...

  9. CSS3 flexbox 布局 ---- flex 容器属性介绍

    flexbox布局是CSS3中新增的属性,它可以很轻松地帮我们解决掉一些常见的布局问题,比如导航栏. 我们用普通的方法写导航栏,通常会在ul, li 结构写好后,让li 元素左浮动,然后再给ul 清浮 ...

  10. Nginx TSL/SSL优化握手性能

    L:131