编译javac -source 1.4 Test.java 执行java -enableassertions Test
Putting Assertions Into Your Code There are many situations where it is good to use assertions. This section covers some of them: Internal Invariants Control-Flow Invariants Preconditions, Postconditions, and Class Invariants There are also a few situations where you should not use them: Do not use assertions for argument checking in public methods. Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException). An assertion failure will not throw an appropriate exception. Do not use assertions to do any work that your application requires for correct operation. Because assertions may be disabled, programs must not assume that the boolean expression contained in an assertion will be evaluated. Violating this rule has dire consequences. For example, suppose you wanted to remove all of the null elements from a list names, and knew that the list contained one or more nulls. It would be wrong to do this: // Broken! - action is contained in assertion assert names.remove(null);The program would work fine when asserts were enabled, but would fail when they were disabled, as it would no longer remove the null elements from the list. The correct idiom is to perform the action before the assertion and then assert that the action succeeded: // Fixed - action precedes assertion boolean nullsRemoved = names.remove(null); assert nullsRemoved; // Runs whether or not asserts are enabledAs a rule, the expressions contained in assertions should be free of side effects: evaluating the expression should not affect any state that is visible after the evaluation is complete. One exception to this rule is that assertions can modify state that is used only from within other assertions. An idiom that makes use of this exception is presented later in this document.
good, 学一招。是自己没看清楚提示，我怎么看成“assert is not a keyword”的啊，真丢脸。
不过我想JAVA中肯定会有assert这个东西的，在书中它和异常(exception)并列，叫作“断言”(assertion)。介绍说它是类似于C++中的#define DEBUG，应该是在调试时候用的。希望各位大侠能够帮忙求解~
执行java -enableassertions Test
There are many situations where it is good to use assertions. This section covers some of them: Internal Invariants
Control-Flow Invariants
Preconditions, Postconditions, and Class Invariants
There are also a few situations where you should not use them: Do not use assertions for argument checking in public methods.
Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, or NullPointerException). An assertion failure will not throw an appropriate exception. Do not use assertions to do any work that your application requires for correct operation.
Because assertions may be disabled, programs must not assume that the boolean expression contained in an assertion will be evaluated. Violating this rule has dire consequences. For example, suppose you wanted to remove all of the null elements from a list names, and knew that the list contained one or more nulls. It would be wrong to do this: // Broken! - action is contained in assertion
assert names.remove(null);The program would work fine when asserts were enabled, but would fail when they were disabled, as it would no longer remove the null elements from the list. The correct idiom is to perform the action before the assertion and then assert that the action succeeded:
// Fixed - action precedes assertion
boolean nullsRemoved = names.remove(null);
assert nullsRemoved; // Runs whether or not asserts are enabledAs a rule, the expressions contained in assertions should be free of side effects: evaluating the expression should not affect any state that is visible after the evaluation is complete. One exception to this rule is that assertions can modify state that is used only from within other assertions. An idiom that makes use of this exception is presented later in this document.