There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
linus dale wrote:is it necessary to have "throws someexception" in the method's declaration ?
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
SCJP 5.0, SCWCD 5.0, SCBCD 5.0, SCJD, SCEA in progress
www.ulisespulido.com
1. My book says "if your method is defined with a throws clause, don't forget to actually throw your exception in the body of the method using the throw statement". So if I use a "throws" clause in my method because it could possibly throw an exception during an exceptional circumstance, I have to throw it? I thought that I was listing the exceptions in the clause in case they are thrown.
2. Listing the exceptions in the throws clause in the method signature is for passing those exceptions back up the calling chain without actually handling them in the current method, correct? As was already said, it is just for letting the compiler and other human users of your method to know what methods may get passed back to them for handling, correct?
3. Where do the exceptions that you do not actually throw yourself come into this, such as ArrayIndexOutOfBoundsExceptions, EOFExceptions, etc.? Are these considered "Checked" or "Unchecked" exceptions? If I needed to throw these manually (such as a circumstance where I needed to partially deal with the exception and then re-throw it to be passed up the method calling chain), do I just make an instance and throw it as normal?
4. If I don't use a "throws" clause in my method signature, and an exception occurs that I don't handle in my method, is it still passed up the calling chain? Or is it required to use the throws clause to pass exceptions up the chain to be handled by a calling method.
5. As for passing exceptions up the chain to be handled by a calling method, those calling methods would just need to wrap the method call in its own try/catch block to handle it, correct?
David Newton wrote:
1. My book says "if your method is defined with a throws clause, don't forget to actually throw your exception in the body of the method using the throw statement". So if I use a "throws" clause in my method because it could possibly throw an exception during an exceptional circumstance, I have to throw it? I thought that I was listing the exceptions in the clause in case they are thrown.
I don't think a method even has to have the *possibility* of throwing a throws exception, but obviously that would be misleading and create unnecessary work for the method's callers. But no: declaring an exception in throws just means the method could throw the exception--otherwise every method that declares exceptions would always throw them, and they obviously don't... and what about methods that declare multiple exceptions?
2. Listing the exceptions in the throws clause in the method signature is for passing those exceptions back up the calling chain without actually handling them in the current method, correct? As was already said, it is just for letting the compiler and other human users of your method to know what methods may get passed back to them for handling, correct?
What exceptions might get thrown that need handling (or passing up the call chain).
3. Where do the exceptions that you do not actually throw yourself come into this, such as ArrayIndexOutOfBoundsExceptions, EOFExceptions, etc.? Are these considered "Checked" or "Unchecked" exceptions? If I needed to throw these manually (such as a circumstance where I needed to partially deal with the exception and then re-throw it to be passed up the method calling chain), do I just make an instance and throw it as normal?
Every exception is either checked or unchecked; you need to look at each one to determine which it is (although an IDE will warn you if you haven't caught a checked exception or declared it in the method's throws clause.
Exceptions may be re-thrown, or new ones constructed.
4. If I don't use a "throws" clause in my method signature, and an exception occurs that I don't handle in my method, is it still passed up the calling chain? Or is it required to use the throws clause to pass exceptions up the chain to be handled by a calling method.
An un-caught and undeclared (via throws) checked exception is a compilation error. An unchecked exception will bubble up.
5. As for passing exceptions up the chain to be handled by a calling method, those calling methods would just need to wrap the method call in its own try/catch block to handle it, correct?
Yes.
What book are you reading? Most of these should have been covered in any reasonable Java book. Also, in general, it's best to start new threads for new questions--these are quite different than the original question.
It's "SAMS" not "Sam's" and the book must have improved a lot; I have a copy and don't think at all highly of it.Tim Crouch wrote: "Sam's Teach Yourself Java 6 in 21 Days".
Or, everybody you ask tells you something different :wink:The number of conflicting opinions gathered about Java exceptions is equal to the number of people asked.
Don't get me started about those stupid light bulbs. |