java之assert关键字用法案例详解

Java2在1.4中新增了一个关键字：assert。在程序开发过程中使用它创建一个断言(assertion)。，它的语法形式有如下所示的两种形式：

1、assert condition;
这里condition是一个必须为真(true)的表达式。如果表达式的结果为true，那么断言为真，并且无任何行动
如果表达式为false，则断言失败，则会抛出一个AssertionError对象。这个AssertionError继承于Error对象，
而Error继承于Throwable，Error是和Exception并列的一个错误对象，通常用于表达系统级运行错误。

2、asser condition:expr;
这里condition是和上面一样的，这个冒号后跟的是一个表达式，通常用于断言失败后的提示信息，说白了，它是一个传到AssertionError构造函数的值，如果断言失败，该值被转化为它对应的字符串，并显示出来。

用一个例子说明一下：

public class Test {
    public static void main(String[] args) {
        System.out.println("start");
        assert true;
        System.out.println("go on");
        assert false:"stop";
        System.out.println("end");
    }
}

这里有一个测试类，通过之前简单的语法介绍后，可以这样简单的理解这个例子：

当程序运行到assert true这一句时，condition为true，系统会继续执行下去。而后执行到 assert false:"stop"的时候，由于condition=false，系统会抛出AssertionError。

但是试试上是不是这样的呢？

看看运行结果就知道了

start
go on
end

这个运行结果和我们一开始的预期不一致，问题出在哪里了？

原来java的断言与C语言中的断言还有有些不同的地方。

Java的assertion的开启也和C语言不太一样，在C语言中，assertion的开启是在编译时候决定的。当我们使用debug方式编译程序时候，assertion被开启，而使用release方式编译时候，assertion自动被关闭。  而Java的assertion却是在运行的时候进行决定的。其实，这两种方式是各有优缺点。如果采用编译时决定方式，开发人员将处理两种类型的目标码，debug版本和release版本，这加大了文档管理的难度，但是提高了代码的运行效率。  Java采用运行时决定的方式，这样所有的assertion信息将置于目标代码 中，同一目标代码可以选择不同方式运行，增强目标代码的灵活性，但是它将牺牲因为assertion而引起一部分性能损失。    

说直白一点就是：assert关键字需要在运行时候显式开启才能生效，否则你的断言就没有任何意义。

如果需要观察断言的运行情况，就需要打开系统类的assertion功能 ，我们可使用-esa参数打开，使用 -dsa参数关闭。  -esa和-dsa的全名为-enablesystemassertions和 -disenablesystemassertions，全名和缩写名有同样的功能。

我们还是用刚刚那个测试方法，再执行试试看：

当我们只是通过java命令编译、执行测试方法时，并没有执行assert语句；然而通过java -ea Test命令显示打开assertion功能后，发现系统确实执行了assert语句。

另外，我们注意到体统抛出的是AssertionError，作为Error的一个子类，而不是 RuntimeException。Error代表一些异常的错误，通常是不可以恢复的，而 RuntimeException强调该错误在运行时才发生的特点。AssertionError通常为非常关键的错误，这些错误往往是不容易恢复的，而且assertion机制也不鼓励程序员对这种错误进行恢复。

通过这个实验的现象，可以引发一些思考：

1.assert需要显示的开启生效才有作用。

这就意味着你如果使用IDE工具编码，调试运行时候会有一定的麻烦，因为基本上java IDE都是没有开启断言功能的。并且，对于Java Web应用，程序代码都是部署在容器里面，你没法直接去控制程序的运行，如果一定要开启-ea的开关，则需要更改Web容器的运行配置参数。这对程序的移植和部署都带来很大的不便。

2.assert断言失败将面临程序的退出。这在一个生产环境下的应用是绝不能容忍的。一般都是通过异常处理来解决程序中潜在的错误。但是使用断言就很危险，一旦失败系统就挂了。

3.即使处理了Error，如果断言的代码嵌入到业务流程中，一旦assert失效，也就改变了正常的业务逻辑(如果condition中加入了赋值等操作)。

我想可能就是这些原因导致平时的java开发中几乎不会用到assert关键字，即便如此，JDK中还是存在不少使用assert的地方，比方说java.util.Locale类等

4.是不是可用通过封装一些方法，自己来完成断言的功能，既使用简单，又方便理解。至少我是这样做的。

到此这篇关于java之assert关键字用法案例详解的文章就介绍到这了,更多相关java之assert关键字用法内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！