aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Assertions 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 "Assertions" Watch "Assertions" New topic
Author

Assertions

Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60
Hi friend, I have a doubt.

We know that is not correct to use assertion for validate args in public method. So, in the next example, line 02 is not a good use of asertions.
But, What happen with the line 07? We are using assertion for validate an argument in a private method. This is correct. But, this argument come from a public method!

Thanks and sorry for the english!
Souvik Dasgupta
Ranch Hand

Joined: Sep 24, 2009
Posts: 77



I believe that is against Best-Practice as well since the exposed call is in public method.


Thanks and Regards, Souvik
SCJP, SCWCD, OCEJWSD
Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60
Thanks for response Souvik!

I believe the same, but I am not sure.

Someone knows exactly what is the answer?
Nick Widelec
Ranch Hand

Joined: Feb 28, 2013
Posts: 226

Alam Ameghino wrote:Thanks for response Souvik!

I believe the same, but I am not sure.

Someone knows exactly what is the answer?


I think it's ok as it's checking a post condition, it's allowed even in public methods.
Check out postconditions here http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage-conditions


OCAJP 7, OCPJP 7
Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60
Nick, thanks for the link and your answer.

But, I can not see the answer to me question in this link!

Where do you see the answer in the link?
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Alam Ameghino wrote:
We know that is not correct to use assertion for validate args in public method. So, in the next example, line 02 is not a good use of asertions.



Not sure why you are saying it because line #2 looks perfect to me.

Regards,
Dan

William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60
Hi Dan,

Not sure why you are saying it because line #2 looks perfect to me.


Because you should not use assertion to validate args in public methods!
Nick Widelec
Ranch Hand

Joined: Feb 28, 2013
Posts: 226

Alam Ameghino wrote:Nick, thanks for the link and your answer.

But, I can not see the answer to me question in this link!

Where do you see the answer in the link?


Well, the thing is that when assertions are enabled and the the argument is null, line 2 will throw an AssertionError and line 3 will never get called.
On the other hand if the argument it's not null and the assertions are enabled, it will pass through line 3 and the argument now is assured to be not null by line2! so it is a postcondition in this sense, it further ensures the state (condition) of a field/value. Which is appropriate to do. (even in public methods)

Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60

Hi Nick, and again thanks!

Mmmmm, I am not agree..

You must say if assertions are appropriate or not in COMPILE-TIME, no in RUNTIME-TIME.
Nick Widelec
Ranch Hand

Joined: Feb 28, 2013
Posts: 226

Alam Ameghino wrote:
Hi Nick, and again thanks!

Mmmmm, I am not agree..

You must say if assertions are appropriate or not in COMPILE-TIME, no in RUNTIME-TIME.

The assertions work only at Runtime (if enabled)... at compilation time the compiler just ignore it.

Again the purpose of assertions is at RUNTIME-TIME, to enforce the idea: it throws an AssertionError which works as a RunTimeException, nothing is checked or done at compile time.

Therefore saying that assertions are appropriate at Compile Time there is no sense.. further in the link I above posted is also shown that it's legal using a kind of flow control with assertions enabled as long as there won't be any side effect in the code itself (without assertions).

Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60
I know thtat assertions work only in runtime, but you must say if they are appropiate or not in compile-time.

You don't need run a program for know if assertions are appropiate or nor!
Nick Widelec
Ranch Hand

Joined: Feb 28, 2013
Posts: 226

Alam Ameghino wrote:I know thtat assertions work only in runtime, but you must say if they are appropiate or not in compile-time.

You don't need run a program for know if assertions are appropiate or nor!


I do not think so, to enforce my point I again restate that it's perfectly fine using side effects (hence runtime behaviour) within assertions.
And to give credit to what I say I quote from the link I have already mentioned above


As a rule, the expressions contained in assertions should be free of side effects: evaluating the expression should not affect any state that is visible after the evaluation is complete. One exception to this rule is that assertions can modify state that is used only from within other assertions. An idiom that makes use of this exception is presented later in this document.


The exception that the quote talks about, it's exactly the case we have with line 2 and 3. (There is a side effect within assertions)
Bottom line: line 2 is incorrect, as it is not appropriate checking an argument in a public method, however line 3 per se is correct, it's just a postcondition depending on the result of another assertion.(which is acceptable)

If you say that it must be at compile time, please to quote your reference.

Alam Ameghino
Ranch Hand

Joined: Jun 01, 2011
Posts: 60
I think that my poor ingles is a problem in this case. Sorry.

See friend,

From Kathy and Bert's book

Page 392. Title: Don't use assertions to validate arguments to a public method.

So, it is not correct:

Page 393. Title: Do use assertions to validate argument to a private method

So, it is correct.

But, What happen when in a private method we are validating an argument that belong to the previous public method? The argument is the same, the same object in both.


Thanks Nick.
Sorry if I am not being clear.
Nick Widelec
Ranch Hand

Joined: Feb 28, 2013
Posts: 226

Alam Ameghino wrote:I think that my poor ingles is a problem in this case. Sorry.

See friend,

From Kathy and Bert's book

Page 392. Title: Don't use assertions to validate arguments to a public method.

So, it is not correct:

Page 393. Title: Do use assertions to validate argument to a private method

So, it is correct.

But, What happen when in a private method we are validating an argument that belong to the previous public method? The argument is the same, the same object in both.


Thanks Nick.
Sorry if I am not being clear.


To me line 7 is always correct, at most it would be a wrong usage of the private helper method in line 3 IF line 2 was absent. Although line 2 is NOT correct, it checks whether the argument is null or not. Past line 2 and now being in line 3, m2(s) method is just a postcondition. In order to consider a post condition as the name say, you have to consider the Runtime process of the code.
I do agree that method declared in line 1 m1 does a wrong usage of assertions. However if you take line 3 per se, in that context (after line 2 the argument cannot be null), there is nothing wrong in checking that post condition. If you removed line 2 and the method m1 was only like :


So my point is that line 2 is incorrect but line 3 is ok if put after line 2.

This is my point of view considering what a postcondition is.
Waiting for other opinions on the issue.


 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Assertions
 
Similar Threads
assertions?
Accessing method from the child class
dan exam doubt 12
Dan's questions on assertions: inconsistent?
SCJP exam Query....Assertions....