Coming from C#, I just don\'t get this \'throws exception\' that is written after a class/method definition:
public void Test() throws Exception
To answer your specific question, you almost never want to say throws Exception
per se.
The throws
clause is notifying users of this method that there is an exceptional case that they will have to handle. For example, you might have an IOException
that results from some use of the file manipulating methods (e.g., unable to open the file in question). If you haven't handled that locally, you need to declare that your method throws
that exception back to the caller.
Modern IDEs will notify you that, for checked exceptions, you need to either handle them in your use of the method or throw them out of the method up the call tree (via the throws clause).
In C++ ( I can't C# but it is probably similar ) keyword throw
is a restriction for all of exception types so if there is no specification about throwing exceptions you can suppose that it can be whatever.
In Java you can suppose if there is no usage of keyword throws
then this method throws no one. ( you can be sure, but there needn't be runtime exceptions ). So if there is some specification about throwing you have to catch it of propagate it up
This concept of checked vs. unchecked exceptions doesn't exist in .net. The intention of the original Java guru's was that if you have to declare the checked exceptions that you throw, so the caller will know that he/she has to catch them. for example, if you are dealing with the IO library, if forces you to catch the IOException.
try {
file.delete();
} catch (IOException x) {
// do something
}
Unfortunately checked exceptions are over-used in Java (see spring philosophy). There is a lot of criticism about the abuse of checked exception and how they pollute the code. Libraries that throw checked exceptions more often than not lead the users to write code like this:
try {
file.delete();
} catch (IOException e) {
throw new RuntimeException(e);
}
If you are writing a library, consider whether your checked exception will hinder/annoy the user, and whether he/she benefits from having to catch them.
There are different school of thoughts on this matter, but the overwhelming trend today is to avoid checked exceptions (see successful projects like spring, hibernate, apache-commons, etc.).
I can attest that today I don't throw checked exceptions anymore. If it is really important that the user should know about the exception, then document it well in the javadocs, but give the user the freedom to write cleaner code.
EDIT: I found a similar question (and one of my previous answers) here. Maybe it will help.
Answer more to the topic rather to description: Class can not use "throws" keyword. Only methods and constructors can.
With little hack you can use throws on initialization block (but not static). You can set throws on constructor and then it will compile.
public class Example{ // here you can not use throws
{
BufferedReader in = new BufferedReader(new FileReader("asdf"));
}
public AbstractWithConstantsOnly() throws FileNotFoundException { }
public static void main(String[] args) throws Exception {
new Example();
}
}
Basically yes, and if you don't your program won't compile. This is called a checked exception (Any exception is a checked exception unless it is or extends RuntimeException or Error).
If there is anything in the method which throws an Exception it won't compile unless you either catch the exception or declare it on the method, and then anything calling that method will have to handle the Exception in the same manner.
You have to write it in the case that the exceptions thrown are checked exceptions, which mean that it is the explicit responsibility of the caller to catch or rethrow the exception.