This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
hello people... i did not understand this para in K&B #5 pg 359.. please help me out in understanding this...
Suppose your method doesn't directly throw an exception, but calls a method that does. You can choose not to handle the exception yourself and instead just declare it, as though it were your method that actually throws the exception. If you do declare the exception that your method might get from another method, and you don't provide a try/catch for it, then the method will propagate back to the method that called your method, and either be caught there or continue on to be handled by a method further down the stack.
// when we are declaring the exception with the throws statement then why do we have to provide the try/catch block...???
Originally posted by sonia jaswal: So does that mean that i have to provide try/catch block to that method which calls another method that throws exception....???
Its simple. Let me explain you in detail but in a simple way.
You have 2 methods named method1() and method2(). And assume method1() throws an Exception. method2() calls method1(). You invoke the method2() from your main.
The code would go like this.
If you compile this program, you will definitely get a compiler error at various places.
You should add a "throws" clause to the method which actually throws an exception, but does NOT handle it. That means, a method which has a "throw" statement inside it.
Remember the difference between "throw" vs "throws" here. throws is used to actually throw an exception whereas "throws" indicates that the method is expected to throw an exception. throws goes with the method signature.
Now, you add a 'throws' clause in the method1() which actually throws an Exception. The method syntax goes like this.
The method1() is perfect now. It says that it might possibly throw an exception and that's why it has added a throws clause in its signature. Its safer now.
Now there is a question. You say that an exception is thrown in a method. That exception has to be handled somewhere. You would call that method from one place.
The place of calling might be inside another method that is the starting point of your execution OR anywhere in the middle. That means, inside the main() you may call our methed1() or you call any other method (say method2() here) and let that method call the method1().
Where you handle the exception? You have two choices. Either you can handle the exception in method2() itself. In such case, the method2() has to have a try/catch block.
In this situation, the method2() would have to be defined as
If you don't want the method2() to handle the exception means, only possible way is to let the caller of method2() [here, the main() method which calls your method2()] deal with it. This is what we call "down the stack".
How will you let the compiler and runtime environment know that this method2() is NOT responsible for handling the exceptions?. The same way as method1() does. You add a throws clause to the signature of method2() as
Now, if method1() and method2() both do NOT handle the exception but just throws the exception. Then who? Only option left out is main() method.
You need to remember that main() is also a method like method1() and method2(). So you either need to have a catch block or throws clause in main() method.
I guess you can complete the program with any of the possibilities listed above. Aint I?