Assert在开发时非常有用。当代码正常工作时，某些事情就不能发生。它易于使用，并且可以永远保留在代码中，因为在现实生活中它将被关闭。

如果这种情况在现实生活中有任何可能发生，那么您必须处理它。

我喜欢它，但不知道如何在Eclipse/Android/ADT中打开它。即使在调试时，它也似乎是关闭的。(有一个关于这个的线程，但它指的是“Java虚拟机”，它不会出现在ADT运行配置中)。

下面是我在Hibernate/SQL项目的服务器中编写的断言。一个实体bean有两个有效的布尔属性，称为isActive和isDefault。每个都可以有一个值“Y”或“N”或null，被视为“N”。我们希望确保浏览器客户端仅限于这三个值。所以，在这两个属性的setter中，我添加了这样的断言:

assert new HashSet<String>(Arrays.asList("Y", "N", null)).contains(value) : value;

注意以下几点。

This assertion is for the development phase only. If the client sends a bad value, we will catch that early and fix it, long before we reach production. Assertions are for defects that you can catch early. This assertion is slow and inefficient. That's okay. Assertions are free to be slow. We don't care because they're development-only tools. This won't slow down the production code because assertions will be disabled. (There's some disagreement on this point, which I'll get to later.) This leads to my next point. This assertion has no side effects. I could have tested my value against an unmodifiable static final Set, but that set would have stayed around in production, where it would never get used. This assertion exists to verify the proper operation of the client. So by the time we reach production, we will be sure that the client is operating properly, so we can safely turn the assertion off. Some people ask this: If the assertion isn't needed in production, why not just take them out when you're done? Because you'll still need them when you start working on the next version.

Some people have argued that you should never use assertions, because you can never be sure that all the bugs are gone, so you need to keep them around even in production. And so there's no point in using the assert statement, since the only advantage to asserts is that you can turn them off. Hence, according to this thinking, you should (almost) never use asserts. I disagree. It's certainly true that if a test belongs in production, you should not use an assert. But this test does not belong in production. This one is for catching a bug that's not likely to ever reach production, so it may safely be turned off when you're done.

顺便说一句，我可以这样写:

assert value == null || value.equals("Y") || value.equals("N") : value;

对于只有三个值是可以的，但是如果可能值的数量变大，HashSet版本就会变得更方便。我选择HashSet版本来说明我关于效率的观点。

让我们假设您要编写一个控制核电站的程序。很明显，即使是最微小的错误也可能导致灾难性的结果，因此您的代码必须是无bug的(为了论证，假设JVM是无bug的)。

Java不是一种可验证的语言，这意味着:你不能计算出你的操作结果会是完美的。这样做的主要原因是指针:它们可以指向任何地方，也可以指向任何地方，因此它们不能被计算为这个确切的值，至少在合理的代码范围内不能。对于这个问题，没有办法证明您的代码在整体上是正确的。但你能做的是证明你至少能在bug发生时找到它。

此思想基于契约式设计(Design-by-Contract, DbC)范式:首先定义(具有数学精度)您的方法应该做什么，然后在实际执行期间通过测试来验证这一点。例子:

// Calculates the sum of a (int) + b (int) and returns the result (int).
int sum(int a, int b) {
  return a + b;
}

虽然这很明显可以正常工作，但大多数程序员不会看到其中隐藏的bug(提示:Ariane V因为类似的bug而崩溃)。现在DbC定义您必须始终检查函数的输入和输出，以验证它是否正确工作。Java可以通过断言来做到这一点:

// Calculates the sum of a (int) + b (int) and returns the result (int).
int sum(int a, int b) {
    assert (Integer.MAX_VALUE - a >= b) : "Value of " + a + " + " + b + " is too large to add.";
  final int result = a + b;
    assert (result - a == b) : "Sum of " + a + " + " + b + " returned wrong sum " + result;
  return result;
}

如果这个函数现在失败了，您会注意到它。你会知道你的代码中有问题，你知道它在哪里，你知道是什么引起的(类似于异常)。更重要的是:当它发生时停止正确执行，以防止任何进一步的代码使用错误的值，并可能对它所控制的任何东西造成损害。

Java异常是一个类似的概念，但它们不能验证所有内容。如果需要更多的检查(以降低执行速度为代价)，则需要使用断言。这样做会使代码膨胀，但最终可以在短得惊人的开发时间内交付产品(越早修复bug，成本就越低)。此外，如果代码中有任何错误，您将检测到它。不可能出现漏洞并在以后引起问题。

这仍然不能保证代码没有错误，但它比通常的程序更接近于这一点。

除了这里提供的所有很棒的答案之外，官方Java SE 7编程指南还提供了关于使用assert的非常简洁的手册;通过几个准确的例子，说明了何时使用断言是一个好主意(重要的是，也是坏主意)，以及它与抛出异常有何不同。

Link

总结一下(不仅仅是Java，很多语言都是如此):

“assert”主要被软件开发人员在调试过程中用作调试辅助。断言消息永远不会出现。许多语言提供了一个编译时选项，该选项将导致所有“断言”被忽略，用于生成“生产”代码。

"exceptions" are a handy way to handle all kinds of error conditions, whether or not they represent logic errors, because, if you run into an error-condition such that you cannot continue, you can simply "throw them up into the air," from wherever you are, expecting someone else out there to be ready to "catch" them. Control is transferred in one step, straight from the code that threw the exception, straight to the catcher's mitt. (And the catcher can see the complete backtrace of calls that had taken place.)

此外，该子例程的调用者不必检查子例程是否成功:“如果我们现在在这里，它一定成功了，因为否则它会抛出异常，我们现在就不会在这里!”这种简单的策略使得代码设计和调试变得非常非常容易。

异常方便地允许致命错误条件保持原样:“规则的异常”。而且，对于它们来说，由代码路径来处理，这也是“规则的例外……“高飞球!”

断言主要用于调试应用程序，或者用于替换某些应用程序的异常处理，以检查应用程序的有效性。

断言在运行时工作。这里有一个简单的例子，可以非常简单地解释整个概念——assert关键字在Java中做什么?(WikiAnswers)。