我的问题是从语言设计的角度来看。
为什么断言处理方式不同，即它引发错误而不是异常，默认情况下不会启用等等。
它确实看起来很优雅（非常主观的意见），易于阅读（再次主观）进行验证＆amp;还有一些工具（IDE）可以对它进行实时评估，并根据断言提供警告。
答案 0 :(得分：6)
我要说的原因是Java的默认值是为了构建软件的“发布”版本 - 如果用户需要构建你的代码，他们将使用提供的默认值，如果你是开发人员，并希望更好地报告你总能做出一些额外的努力。
通常您不希望发布带有发布版本的断言。为什么？您始终可以设计代码以执行一些不令人不安的背景错误处理，并且在用户面前抛出AssertionError并不总是可行的方法。
大多数时候我看到它们被用作额外的代码测试 - 当你运行回归测试并且代码覆盖率很高时，没有断言错误表明你的代码中没有（显而易见的）错误。如果发生某些情况，您可以从堆栈跟踪中推断出出现了什么问题以及原因。另一方面，客户不应该看到描述性错误信息。
那么你应该如何使用它们呢？根据我的经验，您应该设计代码以不使用断言来执行错误处理。如果你想在某处抛出异常，请自己明确抛出它。一旦代码可以自己处理，你可以添加断言来检查前置条件和后置条件以及不变量 - 所以基本上用它们来检查算法的正确性而不是数据的正确性。它对开发人员而不是用户有价值。一旦你对你的解决方案有足够的信心，就可以禁用断言，你的程序仍能正常工作，你的用户不必运行带有额外运行时开销的程序。
答案 1 :(得分：3)
断言是开发人员的工具。
默认情况下未启用的主要原因是通过assert的断言并不旨在为生产代码提供运行时验证/保护。
assert是用于开发过程和测试期间的工具，不会在生产环境中的实际运行中影响性能。
想象一下一个非常重的断言，这些断言对于构建新功能或在整个允许输入范围内进行更改时进行检查至关重要，但是一旦构建并经过正确测试，就无需运行，直到再次更改代码。 / p>
答案 2 :(得分：0)
它会引发错误，因为断言违规的严重程度足够高。
Exception的示例类似于ArrayIndexOutOfBounds。在某些情况下这可能是合理的，您甚至可能期望（并处理）这种情况。
但是，断言违规（例如内存不足）是你没想到或想要处理的。这是一个错误，没有任何借口。
默认情况下不启用断言，因为它们应始终为fullfilled。你让他们测试那个，但是你知道＆＃34; （据你所知），他们没有受到侵犯。因此，您不需要每次在生产代码中检查条件（可能是性能密集型）。
Java中断言的好处是，当没有启用断言时，实际执行检查的代码永远不会被执行。
例如：
if (!doComplexChecks()) throw new AssertionError("Damn!");
可能需要花费大量时间，并且您希望在单元测试或调试时验证这一点，但在生产中您只是不想要这样做。
但是这段代码
assert doComplexChecks();
，这样可以节省大量的生产代码时间。