讨论一下：java断言没有实用价值

我有问题,除了Junit单元测试,你还在什么地方使用断言了?

assert 其实你可以认为它就是个语法糖，用来简化你的代码量的，

 

比如，像下面这个代码:

public class Test {
	public void method(int i) {
		assert i > 0 : "i 必需大于 0";
	}
}

 

编译器在编译期间动了手脚了，它会帮你转成类似下面的代码:

 

public class Test {
	static boolean $assertionsDisabled = !Test.class.desiredAssertionStatus();

	public void method(int i) {
		if (!$assertionsDisabled && !(i > 0)) throw new AssertionError("i 必需大于 0");
	}
}

 

我至今觉得是鸡肋。。鸡肋。。

断言如此设计本身是在运行时免除部分计算,增强效率.
在不考虑代码执行效率的情况下,是没有意义的.

非常有同感，除了用junit做测试的时候，其他地方还真没用过断言。

不是在讨论如何用junit测试webservice，我是在说java assert的真正意义何在。
java断言的意义在于进行函数入参，返回值，或者一些条件值的判断，但是java assert的做法太过粗暴，直接就抛出一个Error，runtime的不能捕捉也不可控，考虑以下场景

1. 函数入参，返回值判断
   采用if-else可以有效进行日志记录，数据库日志记录，可以选择抛出应用基本的异常，对于调用方来说可捕获，可控。

2. 接口调用，包括webservice
   一般一个定义良好的系统，在接口规范中还定义了诸多错误返回（API的话有可能是应用级别的exception），我们可以通过if-else来控制返回什么错误，而不是像java assert一般搞出一个Error出来，完了啥事都没法干。

所以我感觉在程序代码中使用java assert没必要。

完了再讨论单元测试代码，没错，testng用到了java assert，不过现在junit4也有annotation，在单元测试的范畴里面我干嘛还用testng呢？
看了楼上诸位的留言我澄清一下，junit4的断言不是jdk assert，而testng使用的是jdk定义的assert。

可能说的太长没人愿意看，换句话问问，你们项目中，除了testng，你们在什么地方会用到java的assert，是什么理由让你选择抛出一个Error，而不是一个应用级别的错误？

assert既然是抛出error，那么我们如果要用就得顺着这个思路用。
error一般认为是无法恢复的错误。
比如save(Object aobject){ assert aobject !=null: "null object";...}
这关乎设计策略。到底保存一个空对象是允许的，还是禁止的。


也许我们大多数实际情况下，根本不区分excepion和error，就像南方人不区分后鼻音和前鼻音，所以，我们只用到exception就满足了。
或者我们不敢抛出error，一味抛出可捕获的excepion，怕error就把程序结束了。

error......
谁允许你们在正式环境下开启断言了?
C语言老师教的么?

断言是为了在开发过程中定位开发错误问题
在没有ide 的 debug之前想要定位错误
log是没有办法的办法
assert是先进的生产动力.
现在这个assert感念用在了测试上
从源码中剥离出来了.
还可以不用停止在第一个错误之上