• 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

Assertion doubt in K&B

 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
K & B says its sometimes advisable to throw an assertion error even if assertion have been disabled.

Can anybody elaborate on this with a real life situation. I have absolutely not being using assertion in my codes.

Regards
jacob
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no reason why you cannot put:

in your code to detect if something really bad happens. It would be used more when an "impossible" condition occurred and your program cannot in any way recover.
 
author
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's possible to throw an assertion error any time. The statement



will always execute, whether or not the JVM has assertions enabled. But the statement



will only execute if assertions are enabled.

So much for what's possible. As for what's advisable, it's partly a matter of taste, but I would never explicitly throw an AssertionError. I use the assertions mechanism to indicate a precondition violation in a private, default, or (sometimes) protected method. I also use assertions to indicate a postcondition violation in any method, regardless of its access modifier. And that's all that I use assertions for. For any other kind of trouble, I look for an exception class with a name that does a really good job of desribing the trouble. If I can't find one, I create my own.

Hope this helps. If this precondition/postcondition stuff is unclear, let me know and I'll clarify it.

Regards,
Phil
 
Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
did u just mean by precondtion as...check arugement in default,private or protected method ..?

and by post condition whether particular statement will be reached or not and if reached it must throw error...

but why we will use throw new AssertionError("Stress!");
when we will know its going to stop program...
as it will not be caught ?
and what if we try to catch with Trowable catch block ?

can u put light on the above ...
 
Philip Heller
author
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, a precondition check is a check on a method's args, at the beginning of the method. A precondition can also involve checking the validity of the current class' state (which might depend of the state of other classes).

A postcondition check makes sure that the return value is valid, and that the current class' state is valid.

I can't think of any good reason to throw new AssertionError("Stress!");
As I said earlier, it's better to use the "assert" keyword. Then the JVM will throw the AssertionError automatically, if assertons have been enabled.

Stepping back and looking at the big picture, when should assertions be enabled. This relates to the issue of checked vs. runtime exceptions: some problems should never occur in commercial-grade code, while others (like IOExceptions) can't be avoided. Similarly, assertions are for checking for problems that should only come up during code development. Such bugs should be eliminated before the software is delivered. For example, a precondition failure in a private method means that somewhere in the class someone is calling the method in an inappropriate way. When this happens during code development, the program should stop running immediately so that the bug can be fixed.

Customers don't want to be exposed to the output from pre- and post-condition checks, and if a bug unfortunately gets shipped to them, they don't want the application to shut down, because they'll lose all their work. So they will run code with assertions disabled.

For more on all this assertions stuff, see Chapter 5 of the 5.0 rev of "Complete Java 2 Certification".
 
amit taneja
Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok ...but why you are doing so much advertisement of ur book only...

don't mind

regards,
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic