• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

questions about assert

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Which statements are true?

a. If assertions are not enabled at run time it prints an error message.
b. If assertions are not enabled at run time it prints nothing.
c. With assertions enabled it prints an error message.
d. With assertions enabled it prints nothing.
e. The assert statement is being used to check a class invariant--something that must be true about each instance of the class.
f. The assert statements are being used to check a precondition--something that must be true when the method is invoked.


========================
answers: b,d,e
My question is, why "e" is one of the answer?
And what does class "invariant" mean?



Which statements are true?

a. With assertions enabled it prints an error message.
b. With assertions enabled it prints: true,true,false
c. With assertions disabled it prints an error message.
d. With assertions disabled it prints: true,true,false
e. With assertions disabled it prints nothing.
f. The combination of the if/else statements and the assert statement indicate that the programmer expects no more than one boolean, b1, b2 or b3, to be true.
g. The assert statement is being used to check a precondition--something that must be true when the method begins.
h. The assert statement is being used to check an internal invariant--something that the programmer assumes to be true at a particular point in the program.


==================
answers: a,d,f,h
My question is, the answer "f",how do we know what programmer expect?


Thans a lot.

([C0DE][/C0DE] tags added)
[ August 26, 2004: Message edited by: Barry Gaunt ]
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please quote the source of your questions.
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
these are questions from dan's mock
 
Sandya Bhaskara
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

read this...great explanation about assertions!
 
Sandya Bhaskara
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[B]INTERNAL INVARIANTS[\B]
Before assertions were available, many programmers used comments to indicate their assumptions concerning a program's behavior. For example, you might have written something like this to explain your assumption about an else clause in a multiway if-statement:

if (i % 3 == 0) {
...
} else if (i % 3 == 1) {
...
} else { // We know (i % 3 == 2)
...
}
You should now use an assertion whenever you would have written a comment that asserts an invariant. For example, you should rewrite the previous if-statement like this:

if (i % 3 == 0) {
...
} else if (i % 3 == 1) {
...
} else {
assert i % 3 == 2 : i;
...
}
Another good candidate for an assertion is a switch statement with no default case. The absence of a default case typically indicates that a programmer believes that one of the cases will always be executed. The assumption that a particular variable will have one of a small number of values is an invariant that should be checked with an assertion. For example, suppose the following switch statement appears in a program that handles playing cards:

switch(suit) {
case Suit.CLUBS:
...
break;

case Suit.DIAMONDS:
...
break;

case Suit.HEARTS:
...
break;

case Suit.SPADES:
...
}
It probably indicates an assumption that the suit variable will have one of only four values. To test this assumption, you should add the following default case:

default:
assert false : suit;
If the suit variable takes on another value and assertions are enabled, the assert will fail and an AssertionError will be thrown.

An acceptable alternative is:

default:
throw new AssertionError(suit);

This alternative offers protection even if assertions are disabled, but the extra protection adds no cost: the throw statement won't execute unless the program has failed. Moreover, the alternative is legal under some circumstances where the assert statement is not. If the enclosing method returns a value, each case in the switch statement contains a return statement, and no return statement follows the switch statement, then it would cause a syntax error to add a default case with an assertion. (The method would return without a value if no case matched and assertions were disabled.)


[B]CONTROL FLOW INVARIANTS:{\B]

The previous example not only tests an invariant, it also checks an assumption about the application's flow of control. The author of the original switch statement probably assumed not only that the suit variable would always have one of four values, but also that one of the four cases would always be executed. It points out another general area where you should use assertions: place an assertion at any location you assume will not be reached. The assertions statement to use is:

assert false;
For example, suppose you have a method that looks like this:

void foo() {
for (...) {
if (...)
return;
}
// Execution should never reach this point!!!
}
Replace the final comment so that the code now reads:

void foo() {
for (...) {
if (...)
return;
}
assert false; // Execution should never reach this point!
}


[B]PRE CONDITIONS AND POST CONDITIONS:[\B]

Do not use assertions to check the parameters of a public method..but u can use to check parameters of non public methods
Classes designed for multithreaded use often have non-public methods with preconditions relating to whether or not some lock is held...u can use assertions to check these conditions
You can test postcondition with assertions in both public and nonpublic methods.


[B]CLASS INVARIANTS:[\B]
A class invariants is a type of internal invariant that applies to every instance of a class at all times, except when an instance is in transition from one consistent state to another. A class invariant can specify the relationships among multiple attributes, and should be true before and after any method completes
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Assertions should not be used for argument checking in public methods. I understand this part.

But, would that mean we can use assertions for argument checking in private or protected methods?

Thanks,

Vydhehi
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic