-2

I have googled and read many answers on try,catch and throws. I still cannot get my question answered.

My question is, we try a code and if exception occurs, the execution terminates right away and catch takes care of the rest. In fact we define the scope of exception by declaring a class (along instance) in the parenthesis catch(IOException e)

This further acts as per our code within the block..say, print the error

{
     e.printStackTrace();
}

Whereas, in case of throws, we do the same what we do in catch, personally declare the classes within parenthesis after throws which we expect to be the source of exception we expect. 

.
.
}
catch(Exception e)
{
     e.printStackTrace
}

And if it occurs, execution terminates, gets back to the caller and ultimately executes try catch itself.

So I really can't understand as to what makes throws so special. (Kindly do not confuse with complex answers. You can assume I am a beginner and I am sure, a preacher knows how to make ANYone understand the concepts).

Shridhar
  • 333
  • 1
  • 3
  • 15

2 Answers2

1

throws is used to tell the callers of a method: Beware! if you call this method, you might get an IOException. So you'll have to deal with it. So you use throws to tell people about exceptions you throw.

catch is used by a caller of a method to say: if this method call happens to throw an IOException, I'll handle it the following way. So you use catch when you know how to handle an exceptional situation caused by a method you call.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
1

throws is not strictly necessary from a language design point of view. In fact, a lot of languages don't use it.

The requirement to define the (checked) exceptions thrown by a method using throws was a choice made by the Java creators. It's there to force you, the developer, to be more careful about what you're doing. The idea is that you're supposed to do one of two things with exceptions:

  • Explicitly handle the exception, by catching it, or
  • Explicitly NOT handle it and allow the exception to bubble up to the parent method, which has to make the same decision about handle vs not handle

By doing this, you omit the third possibility: "Just ignore everything and hope nothing breaks", which the Java creators presumably deemed dangerous.

(The third possibility can still be done using non-checked exceptions. This goes against what the Java creators intended, but is what a lot of people and APIs ended up doing anyway.)

BambooleanLogic
  • 7,530
  • 3
  • 30
  • 56
  • 2
    Actually, the use of runtime exceptions instead of checked exceptions is becoming the norm. All newer APIs use runtime exceptions rather than checked exceptions. It's now almost universally accepted that checked exceptions cause more problems than they solve, and should be avoided. BTW, my experience with newbies here confirms that: nearly ALL newbies, when they're forced to deal with a checked exception, choose the wrong solution: catch it and ignore it, which makes the situation worse than if runtime exceptions were used. – JB Nizet Feb 02 '15 at 07:53
  • While I'm not disagreeing with you, I'm talking from the language design point of view, in that this was the idealized intention of the Java creators. The fact that this isn't always how it works in the real word doesn't change what `throws` was designed to do, etc. (Although, I'll change the last sentence to be more accurate to the real world.) – BambooleanLogic Feb 02 '15 at 08:05