It's possible to throw an assertion error any time. The statement
will always execute, whether or not the JVM has assertions enabled. But the statement
will only execute if assertions are enabled.
So much for what's possible. As for what's advisable, it's partly a matter of taste, but I would never explicitly throw an AssertionError. I use the assertions mechanism to indicate a precondition violation in a private, default, or (sometimes) protected method. I also use assertions to indicate a postcondition violation in any method, regardless of its access modifier. And that's all that I use assertions for. For any other kind of trouble, I look for an exception class with a name that does a really good job of desribing the trouble. If I can't find one, I create my own.
Hope this helps. If this precondition/postcondition stuff is unclear, let me know and I'll clarify it.
Consultant to SCJP team.<br />Co-designer of SCJD exam.<br />Co-author of "Complete Java 2 Certification Study Guide".<br />Author of "Ground-Up Java".
did u just mean by precondtion as...check arugement in default,private or protected method ..?
and by post condition whether particular statement will be reached or not and if reached it must throw error...
but why we will use throw new AssertionError("Stress!"); when we will know its going to stop program... as it will not be caught ? and what if we try to catch with Trowable catch block ?
can u put light on the above ...
Thanks and Regards, Amit Taneja
Joined: Oct 24, 2000
Yes, a precondition check is a check on a method's args, at the beginning of the method. A precondition can also involve checking the validity of the current class' state (which might depend of the state of other classes).
A postcondition check makes sure that the return value is valid, and that the current class' state is valid.
I can't think of any good reason to throw new AssertionError("Stress!"); As I said earlier, it's better to use the "assert" keyword. Then the JVM will throw the AssertionError automatically, if assertons have been enabled.
Stepping back and looking at the big picture, when should assertions be enabled. This relates to the issue of checked vs. runtime exceptions: some problems should never occur in commercial-grade code, while others (like IOExceptions) can't be avoided. Similarly, assertions are for checking for problems that should only come up during code development. Such bugs should be eliminated before the software is delivered. For example, a precondition failure in a private method means that somewhere in the class someone is calling the method in an inappropriate way. When this happens during code development, the program should stop running immediately so that the bug can be fixed.
Customers don't want to be exposed to the output from pre- and post-condition checks, and if a bug unfortunately gets shipped to them, they don't want the application to shut down, because they'll lose all their work. So they will run code with assertions disabled.
For more on all this assertions stuff, see Chapter 5 of the 5.0 rev of "Complete Java 2 Certification".
Joined: Mar 14, 2003
ok ...but why you are doing so much advertisement of ur book only...