Regarding to assertions

[David Samer]

Hello people!

I've several doubts about assertions.

First one syntax:

Based on what book says (Kathy Sierra and Bert Bates), there are 2 ways "simple" and "way simple".

(using book examples)

void noReturn() { }
int aReturn() { return 1; }
void go() {
int x = 1;
boolean b = true;
// the following six are legal assert statements
assert(x == 1);
assert(b);
assert true;
assert(x == 1) : x;
assert(x == 1) : aReturn();
assert(x == 1) : new ValidAssert();
// the following six are ILLEGAL assert statements
assert(x = 1); // none of these are booleans
assert(x);
assert 0;
assert(x == 1) : ; // none of these return a value
assert(x == 1) : noReturn();
assert(x == 1) : ValidAssert va;
}
If

Paying attention to the last 3, in the first block of code (lines 10,11 and 12). It's the first time I see it so It gets me confused. What I have clear is the keyword followed by the boolean expression but, the second with the second memeber in the syntax ... I don't get it. Can we place anything there? With anything I mean, any value, method call or even returning values from method calls? (Which is the rule in summary, if there's any, regarding syntax ).


---

The second question , do assertions trigger (happens) when the boolean expression is false?

---

The third question is about, what is does needed to be known about this subject. I've read it all and yet I haven't got it clear at all. I believe the important part (in order to be focused on the exam) is to know :

1) you can't use assertions for public methods to validate arguments.
2) the opposite as 1), can use assertions for private methods to validate arguments
3) you can't use them for command line arguments (this one looks quite obvious)
4) you can use them to check cases you know are never (ever) suppose to happen.

Point 4 gives an example:

switch(x) {
case 1: y = 3; break;
case 2: y = 9; break;
case 3: y = 27; break;
default: assert false; // we're never supposed to get here!
}

It's a way to show you simply can't use them in a block of code that will never be reached, am I right?

The explanation:

If you assume that a particular code block won't be reached, as in the preceding
example where you assert that x must be either 1, 2, or 3, then you can use assert
false to cause an AssertionError to be thrown immediately if you ever do reach
that code. So in the switch example, we're not performing a boolean test—we've
already asserted that we should never be there, so just getting to that point is an
automatic failure of our assertion/assumption

If x value doesn't take any value of those, it reaches defaul and code fails, right?

Thank you in advance for your help, knowledge and of course patience

[Anayonkar Shivalkar]

David Samer wrote:but, the second with the second memeber in the syntax ... I don't get it

You can always try executing the code and see what happens What that syntax does is - part after colon must be some value (or a method returning some value); now, when assertion is failed, there will be a nice call stack including AssertionError. The part after colon would be printed on error stack. So, that part would come in handy to check why exactly assertion failed. Obviously, if a method written after the assertion colon and that method returns null, then as mentioned in code, it is illegal syntax.

David Samer wrote:do assertions trigger (happens) when the boolean expression is false?

No. Assertion is checked only when assertion is enabled via command line option (default is disabled). When enabled, assertion is always checked for its value (either true or false). If false, it will throw AssertionError. If true, code will proceed.

David Samer wrote:1) you can't use assertions for public methods to validate arguments.
2) the opposite as 1), can use assertions for private methods to validate arguments
3) you can't use them for command line arguments (this one looks quite obvious)
4) you can use them to check cases you know are never (ever) suppose to happen.

Well, I doubt there is any mechanism to stop a programmer from using assertion for public methods or validating arguments etc., so can't should've been shouldn't

Ideally, assertion should be used only when you are pretty much sure that some specific condition should never ever be happened. Next to this, your code behaviour should never be dependent on assertion. That is because, a user who will run your code, can easilty enable or disable assertion and there's nothing a programmer can do to stop it. To make things even more interesting, Java has provided facility to selective enabling of assertion - i.e. assertion for one class can be enabled and assertion for another class can be disabled at same time e.g. in switch-case snipped you provided, what if default condition happens and user has disabled assertions?

So, moral of the story is - a wrong assertion here and there can blow up the whole code.

I hope this helps.

[Helen Ma]

David Samer wrote:Hello people!

I've several doubts about assertions.

void noReturn() { }
 void go() {
 // the following six are ILLEGAL assert statements
assert(x = 1); // none of these are booleans
assert(x);
assert 0;
assert(x == 1) : ; // none of these return a value
assert(x == 1) : noReturn();
assert(x == 1) : ValidAssert va;
}

One more point I want to add is that if the assertion fail , it will print out something after the the colon. One of the Java Ranchers explaint to us that the statement after the colon should be something that can be output.
For example , this is valid :

 assert(x==1) : j = 12  // assume j is initialized. 

In the above last 3 examples, none of them can return an output. If x==1 is false , there is nothing can be printed when the assertionError is thrown at runtime.
Therefore, the compiler won't compile these three examples.

[David Samer]

Thank you both for the replies , IDE helped too when checking answers.

As always, help much appreciated