• 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:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Question in Exam Cram

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Question 9 in the Sample Test asks 'which method declarations would be suitable to the compiler?'. These methods are throwing an exception. BadTasteException is abstract, and extends Exception. BitterException and SourException both extend BadTasteException.
Here is choice a.
a) public void eatMeth() throws BadTasteException
The answer indicates that choice 'a' is one of the correct answers. But if BadTasteException is abstract it can't be instantiated in the 'throw new' statement. Is it possible to throw an abstract exception? Thanks!
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is not possible to create an instance of an abstract object, but the signature you provided is perfectly legitimate.
Think "Polymorphism".
public void eatMeth() throws BadTasteException
This says that we will be throwing an exception that conforms to the contract specified by BadTasteException. In the method eatMeth() you may throw any sub-class of BadTasteException because as descendants of BadTasteException they fufill the contract specified by BadTasteException's definition. So you could throw BitterException and/or SourException within eatMeth(). This of course assumes that these subclasses are not abstract themselves.
If you think about this in the context of some exceptions you've probably dealt with in the past this probably makes even more sense. An excellent example would be when you deal with IO functions. typically you will set these up in a try/catch block where you "catch" an IOException object. IOException is actually the parent class for a number of exceptions like "FileNotFoundException". Yet when you setup your try catch you don't have to catch every type of IOException individually... You can simply catch the parent if that suits your needs.
Hope this helps!
[ March 02, 2002: Message edited by: Macon Pegram ]
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a REALLY IMPORTANT point. Java is full of references to interfaces and abstract classes - a reference to a "concrete" object can be cast to any class (abstract or not) in its parentage or any interface that it or its parents implements.
 
Douglas Wolfinger
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My program that was calling an exception wasn't working. But it was because I forgot to put try { catch() {} } around the method call in main(). So when I put the try-catch in there and declared the method with the superclass exception and threw a subclass, it worked. I think throws is more confusing than meets the eye initially. Thanks again!
reply
    Bookmark Topic Watch Topic
  • New Topic