Lightfire228
Lightfire228

Reputation: 616

What is the point in throws clause?

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

Answers (4)

Stephen C
Stephen C

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

Ed Morales
Ed Morales

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

yitzih
yitzih

Reputation: 3118

If another program uses the method it needs to be able to catch and handle it

Upvotes: 0

Boann
Boann

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

Related Questions