Meaningless Drivel is fun!*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Question on Assertion from KnB's CD 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 "Question on Assertion from KnB Watch "Question on Assertion from KnB New topic
Author

Question on Assertion from KnB's CD

Joyce Lee
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392
Question:
Which two of the followig statements are false? (Choose two)
A. It is never good practice to place assertions where you think execution should never reach.
B. It is never good practice to throw an AssertionError explicitly.
C. Use assertions to verify the arguments of private methods.
D. Don't use assertions to verify the arguments of public methods.
E. Don't handle AssertionErrors with a try-catch block.
Ans: A and B are false.
The explantion for B is that "it is sometimes advisable to throw an assertion error even if assertions have been disabled".
I don't understand the explanation for choice B. Could someone enlighten me?
Thanks!
Joyce
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
Hi Joyce
B. It is never good practice to throw an AssertionError explicitly.

This is false because it is a good practice to sometimes throw an AssertionError explicitly. This is because if you want to check for something even when the assertions are off then you would not be able to check that if the assertions are switched off.
eg.
let say you have a switch statement

Now this default statement could had been like this default : assert false; but this will not work when assertions are disabled.
Secondly let say you have a method which returns something and you don't have any return statement after the switch case then you must have a return or a throw statement in the switch's case and in which case you cannot have just assert false; over there.
[ July 11, 2003: Message edited by: Anupam Sinha ]
Alexandre Ferras
Ranch Hand

Joined: Jun 24, 2003
Posts: 51
A. It is never good practice to place assertions where you think execution should never reach.
FALSE - it�s a GOOD practice to place assertions (IN DESIGN FASE) where you think execution should never reach.
E. Don't handle AssertionErrors with a try-catch block.
FALSE - AssertionErrors should never be handled

The other statements:
B. It is never good practice to throw an AssertionError explicitly
CORRECT - it is sometimes advisable to thrown an assertion error even if assertions have been disabled
C. Use assertions to verify the arguments of private methods.
CORRECT - for private methods is ok, but don�t use in PUBLIC methods
D. Don't use assertions to verify the arguments of public methods.
CORRECT - see above


Time is an excellent teacher; but eventually it kills all its students. <br /> <br />Alexandre Mottin Ferras<br />SCJP 1.5 <br />SCJP 1.4<br />SCWCD 1.3<br />SCBCD<br />IBM Object-Oriented Analysis and Design with UML
Darren McLeod
Greenhorn

Joined: Jul 07, 2003
Posts: 19
Originally posted by Alexandre Ferras:

E. Don't handle AssertionErrors with a try-catch block.
FALSE - AssertionErrors should never be handled

Don't you mean TRUE? I don't think statement E is saying you should handle AssertionErrors.

D. Don't use assertions to verify the arguments of public methods.
CORRECT - see above

I haven't studied assertions that much, why use assertions to verify the arguements of private methods but not public methods?


SCJP, SCBCD
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
Hi Darren
This link might be a good resource for you.
[ July 11, 2003: Message edited by: Anupam Sinha ]
Alexandre Ferras
Ranch Hand

Joined: Jun 24, 2003
Posts: 51
Darren,
not all legal uses of assertions are considered appropriate.
According to Kathy Sierra, Bert Bates book:
E. Don't handle AssertionErrors with a try-catch block.
"AssertionError is a subclass of Throwable, so it can be caught. To discourage you from trying to substitute an assertion for an exception, the AssertionError doesn�t provide access to the object that generated it. All you get is
the String message"
D. Don't use assertions to verify the arguments of public method:
"A public method might be called from code that you don�t control (or have ever seen). Since assertions aren�t guaranteed to actually run (they�re typically disabled in a deployed application), the enforcement won�t happen if assertions aren�t enabled"
Darren McLeod
Greenhorn

Joined: Jul 07, 2003
Posts: 19
Originally posted by Alexandre Ferras:
Darren,
not all legal uses of assertions are considered appropriate.
According to Kathy Sierra, Bert Bates book:
E. Don't handle AssertionErrors with a try-catch block.
"AssertionError is a subclass of Throwable, so it can be caught. To discourage you from trying to substitute an assertion for an exception, the AssertionError doesn�t provide access to the object that generated it. All you get is
the String message"
D. Don't use assertions to verify the arguments of public method:
"A public method might be called from code that you don�t control (or have ever seen). Since assertions aren�t guaranteed to actually run (they�re typically disabled in a deployed application), the enforcement won�t happen if assertions aren�t enabled"

I see, so E and D are TRUE "SUN recommended" statements. Thanks for the clarification.
Thanks Anupam Sinha for the link it was very helpful.
Joyce Lee
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392
Hello, many thanks for the helps.
Based on the information I gathered from the responses, I realized that in certain cases, “throw new AssertionError()” must use in place of “assert”.
Example:
void start(int x) {
switch(x) {
case 0: return 0;
case 1: return 1;
// default: assert false; // this statement will cause compiler error
default: throw new AssertionError(x); // workaround for assert
}
}
The “throw” statement will still be there when the assertion is disabled. A remedy for this is to
default:
if (assertEnabled) // a variable to enable the throw statement
throw new AssertionError(x);
return x;

Now back to the original question I posted:
“It is sometimes advisable to explicitly to throw an assertion error even IF the assertions have been disabled.”
What other advisable scenarios (other than the one mentioned above) are we advised to throw an assertion error even if the assertions have been disabled? The preceding scenario is a must instead of “advisable”. My thinking is that assertions should be used during debugging only.
Any comments are welcomed.
Thanks.
Cheers )
Joyce
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question on Assertion from KnB's CD