difference between throw and throws

throws i believe is used to avoid writing try catch blocks

when is throw used
a small example will help

throw is a verb. throws is... not. :-)

you use 'throws' when you are defining a method to tell the compiler what exceptions the method might possibly throw.

you use 'throw' to actually throw it.

ok, so for throw to be used in the method
is it necessary to have "throws someexception" in the method's declaration ?

does 'throw' have any connection with inheritance
like more useful when there is inheritance

linus dale wrote:is it necessary to have "throws someexception" in the method's declaration ?

Every exception that you throw in any path of your method (including methods you call in your method) that is not an instance of RuntimeException, or a subclass of RuntimeException, needs to be declared. That includes IOException, SQLException and many, many more. However, declaring "throws IOException", for instance, allows you throw IOException and all of its subclasses (like FileNotFoundExecption).

can I use throw in combination with try-catch like above

Well this is my belief:

throws - is a reserved word used in the signature of the method to let not only the compiler but the people who might use your code know what kind of Exceptions they may get if they call that specific method.

public void method throws Exception {
}

throw - launches an exception of the type you specified

throw new RuntimeException();

There is no real connection in using throw and inheritance, of course you can throw whatever that extends Throwable but that's all.

About if is needed to specify in the method, all "checked" exceptions thrown from the method are needed to be in the signature, by checked are all those who extends from Exception, the "unchecked" exceptions are not needed but if your method may throw an specific type of this kind of exceptions I suggest you to add it to the signature not for performance reasons or because your code would not work if you don't put it, it is only because another developer using your method will see easily that he may get an unchecked exception. Unchecked exceptions are the ones that extends from RuntimeException and they are not requiered to be catched or thrown an example of this kind of exceptions is the infamous NullPointerException.

I am having some problems with this concept as well, so I figure I will post my questions here.

I am reading a beginning book about Java 6, and am having some difficulty understanding the concept of exception handling. I guess I will just list all my questions, and hopefully that will clarify it.

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?

Sorry about all these questions, but exception handling has been somewhat of a hard topic for me so far.

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.

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.

Thank you for all the answers! I believe all of this was covered in the book I am reading, but unfortunately, exceptions share a chapter with threads and assertions, so they are somewhat condensed. Other then that, it has been a great book. It is called "Sam's Teach Yourself Java 6 in 21 Days". I have done a bit of reading in pretty much every other major Java book I have access to (vie Safari Books Online), and this one is one of my favorites. I just think that quote I gave in #1 was worded badly.

Thanks again!

Edit- And about asking the questions in this thread, I just assumed that it would be proper forum etiquette to not begin another thread asking about "throw" and "throws" when there was one already there. I thought it seemed to match, but because my problem was generally being confused about some of the concepts, it came out being quite different than the original topic once I had it written.

Tim Crouch wrote: "Sam's Teach Yourself Java 6 in 21 Days".

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.

Have you seen the Java™ Tutorials about exceptions? Have you come across Campbell's rule about Java exceptions?

The number of conflicting opinions gathered about Java exceptions is equal to the number of people asked.

Or, everybody you ask tells you something different :wink:

By the way: If you think you are throwing a checked Exception from a method, it must be declared with the throws keyword. Even if you just might, or an altered form of that method just might, still say throws. If you might throw an unchecked Exception, notify that to users with the @throws tag in the documentation comments. Example here

Please keep "quote" blocks short, otherwise the posts get longer and longer and more and more difficult to read.