The assertion name will appear in stack dumps caused by that exception. As it turns out, by using this form it becomes very easy to turn assertion checking on and off. We wish to produce a version of our code that will run without the safety net of assertion checking. Stack.java to turn off all assertion checking in the file Stack.java. Hoare once said that using array bounds checking when debugging and turning it off on production code is like wearing a life jacket on the shore, but taking it off when you go to sea.
Some people feel the same about contract assertions.
Fortunately, there is some middle ground that turns out to be very useful. If a postcondition is violated, then we can be sure that the problem is in the method implementing the contract. Once an object is well debugged, disabling postcondition assertions carries little risk. On the other hand, if a precondition is violated, the problem is in the client code. Because we cannot control who uses our objects, leaving preconditions enabled seems to be a useful thing to do.