Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Assertion doubt in K&B Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Assertion doubt in K&B" Watch "Assertion doubt in K&B" New topic

Assertion doubt in K&B

thomas jacob
Ranch Hand

Joined: May 19, 2005
Posts: 91
K & B says its sometimes advisable to throw an assertion error even if assertion have been disabled.

Can anybody elaborate on this with a real life situation. I have absolutely not being using assertion in my codes.

Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
There is no reason why you cannot put:

in your code to detect if something really bad happens. It would be used more when an "impossible" condition occurred and your program cannot in any way recover.

Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Philip Heller
Ranch Hand

Joined: Oct 24, 2000
Posts: 119
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".
amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 812
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
Philip Heller
Ranch Hand

Joined: Oct 24, 2000
Posts: 119
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".
amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 812
ok ...but why you are doing so much advertisement of ur book only...

don't mind

I agree. Here's the link:
subject: Assertion doubt in K&B
It's not a secret anymore!