wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Appropriate use of assertions? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Appropriate use of assertions?" Watch "Appropriate use of assertions?" New topic
Author

Appropriate use of assertions?

Boris Mechkov
Ranch Hand

Joined: May 13, 2011
Posts: 72

Please consider the following (Practice Questions K&B OCJP6)



Which are true?
a. Comp. Fails
b. The assertion in line 4 is appropriate.
c. The assertion in line 14 is appropriate.
d. not relevant for my question
e. not relevant for my question
f. not relevant for my question
g.not relevant for my question

Looking at the two assertions and which ones are appropriate, one would notice the assertion 1 (line 4) is in a public method so it is a NO NO!!! Then you would notice that assertion 2 (line 14) is in a private method, which according to the K&B study guide is an APPROPRIATE place to have an assertion, since we more or less control it (private after all)....
Well, unfortunately this is NOT one of the correct answers, and my understanding is because the String [] args passed into the private method is the reason. Still, i am looking at a private method and conclude that assertions there would be appropriate, since this is what i learned from the K&B book...
Can anybody shed some light why this is NOT an appropriate assertion (line 14)?


OCPJP 6
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
This question frustrates me as well.

My interpretation of the assertion on line 4 is that it is functioning as a validation of the command line argument, and that's what makes it inappropriate. (Remember, it's not always inappropriate to use assertions in public methods. There could be intentionally unreachable code, for example, where you might assert false. And it's not inappropriate to use assertions to validate arguments in private methods.) This is all on p. 393 of K&B. So far so good.

I'm not clear how that is the case as well with line 14, which is the only reason I can think of. (Unless we say that the only reason this method exists is to have the args passed to it.) I might in a code review note the ugliness of but that's a different issue than inappropriate.
jishnu dasgupta
Ranch Hand

Joined: Mar 11, 2011
Posts: 103

Hi all,

As far as i remember shoudlnt assertions be used in such a manner that they do not alter the normal flow of the program??..In that case even in the private method, only if the assertion is enabled, thus the if() loop condition produces an error if it comes true. Otherwise the program operates the same, whether it evaluates to true or false.


If debugging is the process of removing bugs, then programming must be the process of putting them in. -- Edsger Dijkstra

Boris Mechkov
Ranch Hand

Joined: May 13, 2011
Posts: 72

jishnu dasgupta wrote:Hi all,

As far as i remember shoudlnt assertions be used in such a manner that they do not alter the normal flow of the program??..In that case even in the private method, only if the assertion is enabled, thus the if() loop condition produces an error if it comes true. Otherwise the program operates the same, whether it evaluates to true or false.

You are absolutely correct. The confusion is that the study guide lists assertion in private methods as Appropriate but the above question says that the assertion in the private method is NOT appropriate (due to String[]s) method argument.
jishnu dasgupta
Ranch Hand

Joined: Mar 11, 2011
Posts: 103

I beleive the only reason for this is the fact that you are dirctly passing an argument that is being provided at runtime, to your privat method, and assuming that it adheres to your assumptions. As the argument is being passed directly from the public method to the private method, without any manipualtions, so i beleive that the assertion on that argument is makiing it illgeal. I am not absolutely sure on ths though.
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

Hello Guys, The K&B book says it is appropriate to use assertions to 'evaluate-arguments' to private methods and it is NOT appropriate for assertions to cause 'side-effects' in methods. Line 14 of the code seems to IMHO cause 'side effects' because whatever the 'if(a.length == 2)' evaluates to, depends on whether assertion is enabled or not, hence it is NOT appropriate, because it is causing side effects, however I think the question is kind of 'ambiguous', I am SURE that in the real exams assertion questions will be less 'ambiguous'.

P.S: When I say 'ambiguous' I mean that the question does NOT specify if assertion is enabled or not. With assertion enabled then it is an appropriate use.


OCPJP 6.
In Your Pursuit Towards Certification, NEVER Give Up.
Achilleas Achix
Ranch Hand

Joined: Apr 18, 2011
Posts: 123

jishnu dasgupta wrote:Hi all,

As far as i remember shoudlnt assertions be used in such a manner that they do not alter the normal flow of the program??..In that case even in the private method, only if the assertion is enabled, thus the if() loop condition produces an error if it comes true. Otherwise the program operates the same, whether it evaluates to true or false.


Assertions, once enabled with "-ea" are supposed to alter the normal flow of the program (if the exceptional condition of the 1st expression evaluates to false). What is not recommended (actually is strongly discouraged) is to have smth like
assert myMethod();
, that is having the code rely on whether the command line switch "-ea" was present or not when the program is invoked.
If myMethod contains useful code that is supposed to run, then this can clearly work only as a subproduct of having put the -ea switch. Otherwise this code would never execute. So what the book writes is to
- NOT include actual/useful code (that we always wish to run) in any of the assert expressions
- Never rely on assertions for input that we cannot control.
- We should use assertions to verify our own code for input that we have processed by our own code. (e.g. inputs to private methods or situations that should never happen, even in public methods)

Back to the question i also believe the problem, seems to be only in the checking of args.


OCPJP 6.0
 
jQuery in Action, 2nd edition
 
subject: Appropriate use of assertions?