• Post Reply Bookmark Topic Watch Topic
  • New Topic

try catch doubt  RSS feed

 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
may i know how should we know where should we use try and catch blocks?

regards,
rahul
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you mean as opposed to declaring "throws"?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • 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 ]
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
  • 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 ]
 
Raj Kumar Bindal
Ranch Hand
Posts: 418
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
good job Bob!!
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks... just something I enjoy doing.
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • 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:

 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • 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
  • 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!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!