• 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

try catch doubt

 
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
may i know how should we know where should we use try and catch blocks?

regards,
rahul
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you mean as opposed to declaring "throws"?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Part 1 of the story is: If any method or constructor throws a "checked exception" it must say so on the method signature.

Part 2 is: If you call a method that says it might throw a checked exception then you must either catch the exception or make your method throw the same exception.

Let's look at OutputStream.write(). That can throw an IO exception and the author had to declare that right on the method.

Now if we want to call someStream.write() the compiler checks to make sure we are aware of it. That's why it's called a "checked exception." We have two choices. In the first example, we just let the exception go up to whatever called us. The compiler is satisfied that we were aware of the possibility of an exception.

In this second example, we handle the exception instead of letting it go. Again we convince the compiler that we understand an exception might happen so it's happy.

Did that make sense?
[ July 24, 2007: Message edited by: Stan James ]
 
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Think of it this way....

You have some kind of animal in your garage hiding out that you dont see but you know he is in there.

If you want to catch him, you have to set a trap. If you don't set a trap you definitely WILL not catch him.

Think of the

try {

}
catch {

}

blocks as "setting the trap".

It doesn't mean that you WILL DEFINITELY get one.....BUT.... if you do anything in the "try block" that DOES generate one you will catch it, presuming your catch block is properly designed.

And, in the case of Java, the compiler will remind you that there is something living in your garage that you had BETTER set a trap for. So if you DON'T set the trap, it will remind you!

-----


--------

Oh....and the traps can come in different sizes (hierarchical types) that you can "layer"..... thus


this is a poor example of inheritance but the idea to get is that your "traps" ( catch block conditions ) should get wider as you go. Put the "more specific" exception types higher and the "less specific/more general" exception types later in the chain. catching something higher up the inheritance chain (in the superclass direction) will certainly catch more subtypes but then you might have to figure out for yourself what type it is. Java allows you to let it do the "filtering" work for you.
[ July 25, 2007: Message edited by: Bob Ruth ]
 
Ranch Hand
Posts: 418
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
good job Bob!!
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks... just something I enjoy doing.
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
However, as Stan was pointing out, its not always appropriate to catch a *checked exception* in the same method where is was first encountered. Sometimes its more appropriate to propagate the exception. You do this by declaring that a *your* method also throws the exception using the 'throws' keyword.

And a try/finally (note no *catch*) can also be useful:

 
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bob Ruth:
Thanks... just something I enjoy doing.



Catching animals?
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Garrett, I could not agree more. Your design goals for handling the underlying problem will have a bearing on that.

Gavin, if need be!
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic