blocks|key|17829|text|它会引发错误，因为断言冲突的严重性足以做到这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|17830|一个异常的例子是类似ArrayIndexOutOfBounds的东西。这在某些情况下可能是合理的，您甚至可能期望(并处理)这样的情况。|offset|length|style|CODE|17831|但是断言冲突是(比如内存不足)没有你想要的或者你想要处理的东西。这是一个错误，没有任何借口。|17832|断言在默认情况下是不启用的，因为它们应该始终是完全填充的。你使他们能够测试这一点，但是你“知道”(就你所能知道的)他们没有被违反。因此，您不需要在生产代码中每次都检查条件(这可能是性能密集型的)。|17833|Java中断言的好处是，当没有启用断言时，实际执行检查的代码永远不会被执行。|17834|例如：|17835|if+(!doComplexChecks())+throw+new+AssertionError("Damn!");|code-block|syntax|javascript|17836|可能要花很多时间，你想在单元测试或调试时验证这一点，但在生产中，你不想这样做。|17837|但是这段代码|17838|assert+doComplexChecks();|17839|只有在启用了断言的情况下才会执行，因此它为您节省了大量的生产代码时间。|17840|entityMap^0|0|A|L|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1B|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1C|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|R|7|1F|8|@]|9|@]|A|$S|T]]|$1|10|3|11|5|6|7|1G|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|13|$]]

It raises an error, because the severity of an assertion violation is high enough to do so.

An example for an Exception is something like <code>ArrayIndexOutOfBounds</code>. This might be reasonable in some cases and you might even expect (and handle) such a case.

But an assertion violation is (like out of memory e.g.) nothing you would ever expect or you would like to deal with. It's an error and there is no excuse.

Assertions are not enabled by default, because they should be always fullfilled. You enable them to test for that, but then you "know" (as far as you can know) that they are not violated. So you don't need to check the conditions (which might be performance intensive) every time in production code.

The good thing about assertions in Java is, that the code actually performing the checks is never executed, when assertions are not enabled.

For example:

<pre><code>if (!doComplexChecks()) throw new AssertionError("Damn!");
</code></pre>

might take a lot of time and you want to verify this when unit testing or debugging, but in production you just don't want that.

But this code

<pre><code>assert doComplexChecks();
</code></pre>

is only executed, when assertions are enabled, so it saves you a lot of time in production code.

blocks|key|4525584|text|我要说的原因是，Java的默认设置是针对产品代码(软件的“发布”版本)的-如果用户需要构建您的代码，他们将使用提供的默认设置，如果您是开发人员，并且想要有更好的报告，您总是可以做一些额外的努力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4525585|通常，您不希望将断言与发布版本一起发布。为什么？你总是可以设计你的代码来执行一些不会干扰后台的错误处理，而在用户面前抛出AssertionError并不总是正确的方法。|offset|length|style|CODE|4525586|大多数时候，我看到它们被用作额外的代码测试--当你运行回归测试并且代码覆盖率很高时，没有断言错误表明你的代码中没有(明显的)错误。如果发生了某些情况，您可以从堆栈跟踪中推断出出了什么问题以及原因。另一方面，客户端不应该为查看描述性错误信息而烦恼。|4525587|那么，您应该如何实际使用它们呢？根据我的经验，您应该将代码设计为不使用断言来执行错误处理。如果您希望在某个地方抛出异常，请自己显式抛出它。一旦代码可以自己处理，你就可以添加断言来检查前置和后置条件以及不变量-所以基本上是用它们来检查算法的正确性，而不是数据的正确性。它对开发人员而不是用户有价值。一旦您对解决方案有了足够的信心，您就可以禁用断言，您的程序仍然可以正常运行，并且您的用户不必运行具有额外运行时开销的程序。|4525588|entityMap^0|0|1O|E|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I'd say that the reason is that defaults for Java are meant for production code (the "release" version of software) - if users need to build your code they will use provided defaults and if you are developer and want to have better reporting you can always make some additional effort.

Usually you don't want to ship assertions with a release version. Why? You can always design your code to perform some not disturbing background error handling and throwing <code>AssertionError</code> in users face is not always the way to go. 

Most of the time I see them used as additional code testing - when you run regression tests and code coverage is high no assertion error suggest that there are no (obvious to spot) errors in your code. If some happens, you can deduce from stack trace what went wrong and why. On the other hand clients shouldn't be bothered with seeing descriptive error information.

So how should you actually use them? In my experience you should design code to not use assertions to perform error handling. If you want exception to be thrown somewhere throw it explicitly yourself. Once code can handle itself, you can add assertions to check pre- and postconditions as well as invariants - so basically used them to check algorithm correctness instead of data correctness. It has value for developers rather than users. Once you have enough confidence in your solution, you can disable assertions, your program still works fine and your users don't have to run program with additional runtime overhead.

blocks|key|17939|text|断言是开发人员的工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|17940|默认情况下没有启用它的核心原因是，通过assert的断言并不意味着要为生产代码提供运行时验证/保护。|offset|length|style|CODE|17941|assert是在开发过程和测试过程中使用的工具，在生产环境中的实际运行过程中不应影响性能。|17942|设想一个非常重要的断言，它在构建新功能或针对整个允许的输入范围进行更改时非常关键，但一旦构建并正确测试，就不需要运行，直到代码再次更改。|17943|entityMap^0|0|J|6|0|0|6|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|M|$]]

Asserts are tools for the developer.

The core reason it's not enabled by default is that assertions via <code>assert</code> are not meant to provide run-time validation/protection for production code. 

<code>assert</code> is a tool for use in development process and during testing that should not impact performance during actual running in production environment.

Imagine a very heavy weight assertions that are critical to check when building out a new feature or a change against a entire range of allowable inputs, but once built and properly tested, don't need to run until code changes again.

My question is from the perspective of language design.

Why is assert treated differently i.e. it raises a error and not an exception, it is not enabled by default etc..

It does seem elegant(very subjective opinion), easy to read(again subjective) for doing validations &amp; also there are tools(IDE) which can live-evaluate it and provide warnings based on assertions.

Why is assert not enabled by default in java

单元测试

回归测试

Java

我的问题是从语言设计的角度提出的。为什么assert被区别对待，比如它会引发错误而不是异常，默认情况下不会启用它等等。它看起来确实优雅(非常主观的观点)，易于阅读(同样是主观的)来做验证&还有一些工具(IDE)可以对其进行实时评估，并根据断言提供警告。

问为什么在java中没有默认启用assert？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在java中没有默认启用assert？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在java中没有默认启用assert？
EN