• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question on Assertion from KnB's CD

 
Joyce Lee
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1090
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Darren McLeod
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Anupam Sinha
Ranch Hand
Posts: 1090
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Darren
This link might be a good resource for you.
[ July 11, 2003: Message edited by: Anupam Sinha ]
 
Alexandre Ferras
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic