• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Master exam question on assertion

 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A master exam question asks to choose true statements but
in the answer the statement
"Never throw an assertion error explicitly"

is marked incorrect.According to me it is a correct statement as we
should neither try to throw nor catch assertion error explicitly
Correct me if i am wrong....
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ujjawal,

it's recommended not to throw an AssertionError explicity.

Since AssertionError is thrown when a statement's boolean test return false and since AssertionError is a subclass from java.lang.Error:

java.lang.Object
--java.lang.Throwable
----java.lang.Error
------java.lang.AssertionError

You can thus throw java.lang.AssertionError as it derives from java.lang.Throwable:

throw new AssertionError();
is nearly the same as:
assert false;

I say "nearly" because the second statement only has effect when assertions are enabled;
if assertions are disabled, the second statement is not even seen by the JVM.

As the name "assertion" says, you assert that s.th. won't come into being (for example, a code fragment won't never be reached) - in order to check this, you can enable assertions while developing.

But after deployment, all things concerning assertions don't have to be an issue any more, so it's not good practice throwing an AssertionError explicity - because in such case, you can't disable a "throw-statement" in a future productive environment.
 
ujjawal rohra
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nice Explanation but i want to know that the master exam question which i quoited is the right answer or not..
Please let me know
 
Ranch Hand
Posts: 310
1
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

ujjawal rohra wrote:Nice Explanation but i want to know that the master exam question which i quoited is the right answer or not..
Please let me know


Hi Ujjawal,

"Never throw an assertion error explicitly"

should be true. Please check the errata for K&B book if this is there
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rajeev Rnair wrote:

"Never throw an assertion error explicitly"

should be true.



No. it is not . you can validate and still throw an AssertionError from *private* method which is not directly called by a client.
but it is not a good idea to throw that(AssertionError which is not understand by user/client) from public method

hth
 
Rajeev Rnair
Ranch Hand
Posts: 310
1
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



No. it is not . you can validate and still throw an AssertionError from *private* method which is not directly called by a client.
but it is not a good idea to throw that(AssertionError which is not understand by user/client) from public method

hth



Why not use "assert false " rather than "throw AssertionError"? If assertions are disabled the code wouldn't execute where as if you use "throw new AssertionError()", disabling assertions wouldn't prevent the error message from kicking in.
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
it is not about enabling or disabling assert ; it is about *throw* an AssertionError .
I saw the throw statement in java API many places, example *java.math.BigDecimal* ; infact by throwing explicitly, you no need to care about to enabling assertion.

normally, when precondition or postcondition vallidation fail in a private method, you can throw an AssertionError.
the below link discussion is bit different from what i said; but anyway it will help to the Original Poster

another discussion on the same

hth
 
Rajeev Rnair
Ranch Hand
Posts: 310
1
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Check this discussion also!
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmm..Rajeev , Ok .

api .

from above link


Thrown to indicate that an assertion has failed.



it didnt mention that you should not throw explicitly . but yes, i am looking some more posts on this
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can you post the ENTIRE question from the master exam?

Thanks,

Bert
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The entire question from the MasterExam is:


Which are true? (Choose all that apply.)
A It is not good practice to place assertions where you think execution should never reach.
B It is sometimes appropriateto call getters and setters from assertions.
C Use assertions to verify the arguments of private methods.
D Assertions can be disabled for a particular class.
E Never throw an AssertionError explicitly.



The reported correct answer is C & D. I also think E should be a correct answer. The explanation for why E is not a correct answer appears to be missing. The Reference simply says:

E is also incorrect.

 
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ryan Slominski wrote:I also think E should be a correct answer.



Hello Ryan...For curiosity why do you think E should be a correct answer?.

If the sentence were like this: "It is appropriate NEVER to throw an assertion error" one might consider it, because the "appropriate" thing to do is to "assert" a situation that may result in true or false. IMHO you can explicitly throw an Assertion error if a conditional test does NOT satisfy your requirement.

Regards

Ikpefua
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's a very poorly constructed question. Only three of the choices (A, B and D) are assertive statements which can be true or false. The other two, C and E, are imperatives which can be neither true nor false, in exactly the same way that the command "open the door" can be neither true nor false. It surprises and disheartens me to encounter this kind of error.
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Dennis Deems wrote:It's a very poorly constructed question. Only three of the choices (A, B and D) are assertive statements which can be true or false. The other two, C and E, are imperatives which can be neither true nor false, in exactly the same way that the command "open the door" can be neither true nor false. It surprises and disheartens me to encounter this kind of error.



Hello Dennis...I respect your criticism, and it is true that the main question itself has a certain degree of "ambiguity", the fact is that writing a computer programming language exam book that has approximately 851pages WITHOUT errors is humanly impossible. That said I think the best way to have asked the question w'd have been as follows:

"Considering the appropriate use of assertions, which of the following are true?"

Regards

Ikpefua.
 
Ryan Slominski
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ikpefua Jacob-Obinyan wrote:why do you think E should be a correct answer



You should never explicitly throw an AssertionError because:

  • You can just use the assert statement (which will delegate to the JVM to throw the Error on your behalf if the condition is met and assertions are enabled)
  • General best practice says you shouldn't throw an Error (The Java Tutorial says this for example: http://download.oracle.com/javase/tutorial/essential/exceptions/throwing.html).


  • Dennis Deems wrote:C and E, are imperatives which can be neither true nor false



    Nice observation. Now that you point it out, it IS a poorly worded question! Even still, I think I understand what C and E are "saying", and I think E should be true.
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic