Reputation: 616
I understand the point of checked exceptions: to remind the developer of errors that you need to be aware of. I also understand the point of not handling some exceptions if you cannot recover from them. But why is it that, should you decide not to handle a checked error, you have to include a throws
statement. If you run this code, you get a runtime error, and should you comment out the throws
statement (and add a {
), you get a compile time error. This seems pointless to throw the error out of main()
if it still interrupts the program.
import java.io.IOException;
public class Blah {
public static void main(String[] args)
throws IOException {
throw new IOException();
}
}
Upvotes: 0
Views: 1199
Reputation: 718708
I understand the point of checked exceptions: to remind the developer of errors that you need to be aware of.
In fact, it is stronger than that. The point is to force the developer (you) to do something about the errors at some point in the application. You can do one of two things:
You can catch and (hopefully) handle the exception in the same method body that it was thrown.
You can add the exception to the throws
list of the method ... so that it propagates to method's caller. That puts the initial responsibility for handling the exception onto the caller code.
In this (general) context, the point of throws
is clear. If the language didn't have throws
declarations, then Java's checked exceptions design wouldn't work1.
As far as the Java Language Spec is concerned, these rules apply equally to all Java methods, including the main
method. So you have to put the "pointless" throws IOException
on your main
. But is it really pointless? I would argue no. Consider the following:
If you allow an exception to propagate out of your application's entry point main
, what happens is that the user sees an ugly stacktrace. As far as he / she is concerned, your application has "crashed".
Isn't it better to be told by the Java compiler that your main
method will "crash" if an IOException
occurs?
Suppose you have two classes in your application which both have a main
method. Should both of them be allowed to propagate checked exceptions without declaring them?
What about the case where an application's codebase includes a specific call to a main
method. Wouldn't it be better to treat such a call just like other calls ... which depends on the main
method declaring the checked exceptions in a throws
clause?
As you can see, there are good reasons for wanting the main
method to follow the same exception rules as other methods.
1 - Either you'd have to catch checked exceptions in the same method they were thrown and library methods couldn't throw checked exceptions, or you'd need to do a global analysis of each application at load time to see if checked exceptions are caught.
Upvotes: 1
Reputation: 1037
The point of being able to "duck" an exception by adding it to the methods throws clause is just the flexibility when creating code that someone else is going to use.. maybe your code gets the exception, but you would rather for the caller of your method to handle it instead of handling the exception yourself, allowing the calling developer to know what happened instead of just re-throwing the exception or returning a null value.
Upvotes: 1
Reputation: 3118
If another program uses the method it needs to be able to catch and handle it
Upvotes: 0
Reputation: 50010
The throws
clause says that a method is allowed to throw certain exceptions. It sets out the contract that the method has with its callers, to let them know which checked exceptions it can throw and thus which exceptions the callers should be prepared to handle, but the called method doesn't have to throw them every time, or at all.
Upvotes: 4