• 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

Dan's mock exam: question on assertion

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(g) A try/catch block should not be used to catch an AssertionError. (correct answer)
but according to JDK 1.4 tutorial page 184, "Since assertions fail by throwing an error, it's possible to catch an assertion failure ... If you do catch an assertion failure, make sure to rethrow it!", which implies that it's ok to catch AssertionError
contradiction?
[ January 19, 2003: Message edited by: Aaron Anders ]
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is factible to catch an AssertionError. But It will defeat it purpose: to know that something was not right -- mainly used in the testing phase.
If an AssertionError is caught what to do with it? You need to know about it. Rethrow it? Why to catch it then?
 
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Aaron,
AssertionError is a subclass of Error.
The javadoc for Error states the following.

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.


There are some things that you should and should not do with assertions.
  • Do not use assertions for argument checking in public methods.
  • Do not use assertions to do any work that your application requires for correct operation.
  • You should use an assertion whenever you would have written a comment that asserts an invariant.
  • A good candidate for an assertion is a switch statement with no default case.
  • You should place an assertion at any location you assume will not be reached.
  • Do not use assertions to check the parameters of a public method.
  • You can, however, use an assertion to test a nonpublic method's preconditions.
  • You can test postcondition with assertions in both public and nonpublic methods.
  • Do not catch an AssertionError.
  •  
    Aaron Anders
    Ranch Hand
    Posts: 39
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    thanks for the clarification
    after re-reading JLS amendment on assertion, i found the following paragraph worth noting,


    Why is AssertionError a subclass of Error rather than RuntimeException?
    This issue was controversial. The expert group discussed it at at length and came to the conclusion that Error was more appropriate, to discourage programmers from attempting to recover from assertion failures. It is, in general, difficult or impossible to localize the source of an assertion failure. Such a failure indicates that the program is operating "outside of known space," and attempts to continue execution are likely to be harmful. Further, convention dictates that methods specify most runtime exceptions they may throw (via "@throws" tags). It makes little sense to include in a method's specification the circumstances under which it may generate an assertion failure. This information may be regarded as an implementation detail, which can change from implementation to implementation and release to release.


    that also explains that we are not encouraged to further process any assertion
    [ January 19, 2003: Message edited by: Aaron Anders ]
     
    Ranch Hand
    Posts: 284
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    interesting read, thanks Aaron.
     
    It was the best of times. It was the worst of times. It was a tiny ad.
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic