Hi all! It was all an easy ride until I reached Exception Declaration and the Public Interface.
Can anybody explain me the stuff here.
Are these two functions ok??? If no, then where is the trouble... do I need to provide a try/catch anywhere, do I need to provide a "throws" for these two methods, if yes, then to which method can i do it, and to which method can I do without them... i would gladly welcome a detailed explaination.
I guess The same example is in K&B book. In do more stuff you are throwing a checked exception. this has to be handled either using try catch or throws clause. If you use throws clause, then method that calls this domore() should also handle this checked exception
Originally posted by Srinivasa Raghavan: I guess The same example is in K&B book. In do more stuff you are throwing a checked exception. this has to be handled either using try catch or throws clause. If you use throws clause, then method that calls this domore() should also handle this checked exception
You are right. It is obviously from K&B and I have read pages 249-250 three times. Still I felt the necessity to discuss it here.
In do more stuff you are throwing a checked exception. this has to be handled either using try catch or throws clause.
Ok, so i must use either try/catch or throws. What if I use both??
And do I need to secure both of my methods??? Can i use try catch for one and throws for the other??? oh someone help me plzzzzzzzzzzzzzzz...
Thanks Seb, browsing page 284-285 from Beginning Java 2 by Ivor Horton, re-reading page 250 from K&B and finally your reply... I end up this way....
Any method which can throw an checked-exception (raised either manually or by the code) has to defend itself. It can either do it by try/catch or by throws.
A try/catch would complety burry the risky thing. So,
1. If the method (doMoreStuff in this case)does by try/catch, then other methods that call it (doStuff in this case)will have no trouble.
2. But if the method (doMoreStuff) simply defends itself by declaring a "throws", then it will escape, however other methods (like doStuff) that call this risky method, will have to defend themselves separately, they can again either chose to supply a "throws" clause or provide the "try/catch" and burry the risk-factor there.
Correct me if I am heading on wrong side... [ September 28, 2005: Message edited by: Akhil Trivedi ]
That is correct, and that is only for checked exceptions.
In the case of checked exception, if you are going to use throws, the method signature should also bear the exception name or the super class of the exception.
if you use try-catch block, then the method signature need not bear the exception name.
Also this is applicable only for checked exception...
in your code if doMore throws NumberFormatException, which is a run-time exception, you do not need to explicilty mention it in the method name.