• 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

Creating and throw(ing) my own exception compile problem

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The following code is a mix of code from p.310 and 333 of Head First Java.

I have a class "TextEx", within which resides a method called "doRisky" which I would like to throw an Exception called "ScaryException", but I am getting some compile errors:

(A) - ScaryException cannot be resolved (or is not an exception type) for the method doRisky.
(B) - ScaryException cannot be resolved or is not a type

I am unsure if I need to "extends Exception" my the class that throws my "custom" exception?

I have tried using just the code on p.310 and 333, but can not get either of them to compile.

Any advice or comments are greatly appreciated,

Nick

[ edited to preserve formatting using the [code] and [/code] UBB tags -ds ]
[ August 11, 2004: Message edited by: Dirk Schreckmann ]
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since you're not using TestEX in your code, why don't change the name of your class to ScaryException?
 
nick wall
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rovas,

Thanks for your reply. But then my class would have the same name as the exception(?)

What would I do if I had multiple methods i my class;doA(), doB(), docC()..etc and I want each one to throw a different exception.

doA() throws ExceptionA{}; doB() throws ExceptionB{}...

I am still confused as to what I am doing incorrectly in my example.

Thank again.

Nick
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Every new exception class that you create needs to extend Exception. When you say 'throw new ScaryException()' your saying throw a new exception object of type ScaryException - new doesn't create a new class but a new object of a class that must be defined.
 
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nick,

Ok let's back up a minute and talk about exceptions. Exceptions are classes, just like any other class in Java. You use them to store(or encapsulate) information you would like to communicate to another class calling the method that throws the exception, like a message explaining to the caller why the exception was thrown. There are two types of exceptions that are practical to discuss, checked exceptions and runtime exceptions.

A checked exception is a subclass of java.lang.Exception and uses compile time checking to make sure the developer is handling it. This usually means that the Exception is handling something that is readily foreseeable(generally). An example of this is an IOException on a BufferedReader for a file. If we try to read from a file that does not exist, we need to know that the read method for the file failed so we can do something appropriate about it, so the compiler forces us to handle it(by using a try/catch block) or delegate it up the call stack(by re-throwing it from the method that called the read method).

RuntimeExceptions are not checked, so they are not enforced by the compiler at compile-time, they pop up at runtime(hence the name). You don't have to handle them explicitly, but you can if you like. An example of this is a NullPointerException, which will be thrown if you call a method on or otherwise try to access a null object reference. In that case it's more of a developer error or logic issue than a foreseeable problem, therefore it's not checked by the compiler.

In your posts, you are talking about checked Exceptions. In your first post, you have a method doRisky that throws a ScaryException. That means you will need a class somewhere called ScaryException that extends Exception, like so:



Your TestEx class does not have to extend Exception, it's not an Exception, it's just an object.

To answer your second question, if you determine that each method must throw a different Exception, then yes, you need to declare it in your throws clause in each method signature. Keep in mind the compiler will make sure something in the method does indeed throw the exception you are specifying, it's a compile-time error if it does not.

Hope that helps,
E
[ August 09, 2004: Message edited by: Eric Fletcher ]
 
nick wall
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Many thanks to Rovas and Eric for taking the time to help me out.

Aha! I get it, and I got it to work in both the example I posted and a new class with multiple methods each with different "checked" exceptions.

I'm getting there!

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