断言是什么？

引用百度百科的介绍，“在程序设计中，断言是一种放在程序中的一阶逻辑，目的是为了标示与验证程序开发者预期的结果－当程序运行到断言的位置时，对应的断言应该为真。若断言不为真时，程序会中止运行，并给出错误消息。”

java的断言是通过assert语句来实现的，用于捕获运行时不应该发生的非法情况。如果在执行断言时，对应的断言为真，啥事都没有发生，如果对应的断言为假，JVM会抛出AssertionError的异常

在java中，assert的语法有以下两种：

/*
* 如果<boolean表达式>为true，则程序继续执行。
* 如果为false，则程序抛出AssertionError，并终止执行。
*/
assert <boolean表达式>;
/*
* 如果<boolean表达式>为true，则程序继续执行。
* 如果为false，则程序抛出java.lang.AssertionError，并输入<错误信息表达式>。
*/
assert <boolean表达式> : <错误信息表达式>;

这样听起来很像是断言就像是一个定制化功能的if语句一样，就像下面代码块的例子

int parameter = 1;
assert parameter!=0;
int parameter = 1;
if(parameter==0){
    throw new AssertionError();
}

那assert与if的区别是什么呢？

assert当然不是一个定制化功能的if。

  1. assert语句仅仅在debug版本中才有效，而在release版本中无效；
    在debug版本中上面的两个代码块的功能一致，但在release版本上assert会被直接忽略掉。
    这个特性也说明了assert主要是用于开发和测试阶段，目的旨在为调试代码，在调试时快速定位问题。如果使用了assert进行业务逻辑的控制，如
int parameter =1 ;
assert (parameter=2)==2;// 这是一个很蠢的演示例子
System.out.println(parameter);

那在release版本中就会出现不一样的结果，因为assert已经修改了正常的业务逻辑。

  1. java在执行assert时默认是不启动断言检查的，无论是什么环境下，如果要开启断言检查，则需要增加命令行参数 -enableassertions 或 -ea 来开启。所以其实release版本也可以使assert生效，只要你想，虽然不是太好。
  2. if是正常程序逻辑的一部分，而assert只是用于调试、定位错误。

再一想，assert的作用不就是在开发阶段进行一些测试，去确保我们业务的正确性，且不影响到我们具体的生产环境。如果是这样的话，用junit写单元测试不是一件更好的事吗？

两者很相似又带着略微的不同，如果是用junit进行单元测试的话，我们会使用到junit所自带的断言语句，例如assertEquals、assertTrue等等，支持更丰富的断言操作。

两者均是用于测试程序，均不影响到生产环境

两者处理问题的维度是不一样的。assert更擅长发现程序具体错误的点，确保不可能的出现的校验条件在实际运行时不会出现；单测则将整个方法当做一个单元进行测试，也是采取断言的方式对运行结果进行校验。

assert需要JVM参数’-ea’来显示启用，单元测试junit中不需要显式启用，就可以使用内置的断言语句。

所以是采用assert还是用单测进行方法的测试，取决于测试的角度。

这个时候就不禁产生新的疑惑，毕竟大多数人似乎都很少在java中用到assert，这是为什么呢？

主要的原因还是因为java自身具备较为完整的面向对象体系(OO体系)，所以我们很少在java中去检查指针是否为空或指针对应的类型是否正确，以及在java中我们很少直接对内存或者缓冲区进行管理，所以也无需检查传入的缓冲区是否为空或已经越界。

说回这篇文章的主角"断言"

在《代码大全 Code Complete》中对断言有这样的理解

  1. 用错误处理代码来处理预期会发生的情况，用断言来处理绝不应该发生的情况
  2. 把断言看作是可执行的注释——你不能依赖它来让代码正常工作，但与编程语言中的注释相比，它能更主动的对程序中的假定做出说明。

assert的目的是为了我们开发者能更容易发现自己的业务逻辑错误，且不影响到程序实际生产的效率。

assert较少被使用到，但并非说是无用的，正确的运用assert有助于提高框架代码的正确性和减少框架代码的使用者的调试时间。