Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Appropriate use of assertions?

 
Boris Mechkov
Ranch Hand
Posts: 72
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)?
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 103
Eclipse IDE Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Boris Mechkov
Ranch Hand
Posts: 72
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 103
Eclipse IDE Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Achilleas Achix
Ranch Hand
Posts: 123
BSD Java Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic