Win a copy of Event Streams in Action this week in the Java in General forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Exception throwing

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following code is valid and compiles but isnt it necessary that a method that might throw an exception has to state it explicitly. If yes then how can this be valid. It does not say: throws IOException in the method statement. Can anyone clarify?
public class aClass
{
public void aMethod()
{
try{
doing()
}
catch(IOException)
{
e.printStackTrace
}
}
}
 
Ranch Hand
Posts: 297
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If an exception might happen, you either have to catch it or declare it to be thrown. In your code, you catch the exception, nothing is thrown. If you didn't catch the exception, you would have to throw it. (Hope I got this right)
 
Gina Pandher
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael
Thank you for the explanation. So if i get it correct, you are saying that there is an option that you can either throw an exception or catch it, not necessary to have both? I mean you CAN have both but its not a rule?
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's no rule that you have to catch an exception that you've thrown, it just makes more sense. If you're taking the time to throw an exception, you might as well make a catch statement to possibly recover from the predicted error that might be "thrown."
In your example, you're trying to catch an IOException, which means you wouldn't have to code your own throw statement when using a method like readLine(), since it has a
/* throw new IOException(); */ statement built into it.
However, if your try/catch block is protecting your code from a method you've written, like your aMethod(), then this method should have a throw statement or your try/catch block is a waste of time. The gaurded clause would be waiting to catch nothing.
I just leanred exception handling two days ago, but I think this is pretty accurate. Experienced users, please correct me if I'm wrong.
 
Michael Hildner
Ranch Hand
Posts: 297
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the above was a pretty good explanation. It is definately not a rule that you have to catch and throw all checked exceptions. But you should be careful about what you do with them.
In general, I think you should catch and handle yourself exceptions your program might throw if you know how to handle it. If you don't think it makes sense to handle it yourself, let the calling method deal with it. Often times they are better equipped anyway.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!