Assertions

[Alam Ameghino]

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!

	public void m1(String s) {
		assert s != null;
		m2(s);
	}
	
	private void m2(String s) {
		assert s != null;
	}

Thanks and sorry for the english!

[Souvik Dasgupta]

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

[Alam Ameghino]

Thanks for response Souvik!

I believe the same, but I am not sure.

Someone knows exactly what is the answer?

[Nick Widelec]

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

[Alam Ameghino]

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]

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

[Alam Ameghino]

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]

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]

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]

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]

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]

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]

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:

	public void m1(String s) {
		assert s != null;  // // it is no correct
	}

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

So, it is correct.

	private void m2(String s) {
		assert s != null;  // 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.

	public void m1(String s) {
		assert s != null;  // it is not correct
		m2(s);
	}

	private void m2(String s) {
		assert s != null; // IS IT CORRECT?
	}

Thanks Nick.
Sorry if I am not being clear.

[Nick Widelec]

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:

	public void m1(String s) {
		assert s != null;  // // it is no correct
	}

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

So, it is correct.

	private void m2(String s) {
		assert s != null;  // 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.

	public void m1(String s) {
		assert s != null;  // it is not correct
		m2(s);
	}

	private void m2(String s) {
		assert s != null; // IS IT CORRECT?
	}

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 :

public void m1(String s)
{
m2(s);//incorrect it's directly checking the argument.
}

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.