Why is throws part of the method signature

Question

Why throws, on a method, is part of its signature? It seems strange to include it. Here is an example where it is in the way:

@Overide
public void foo() {
    throw new UnsupportedOperationException();
}

If anyone were to see this method from the outside, they might try to use it without knowing that it is not supported. They would only learn it on trying to run the code.

However, if they could do something like this they would know by looking at the method that it is not supported and if UnsupportedOperationException was not extending RuntimeException, they would get a compilation error. EDIT1: But this is not possible because throws is part of the signature so override will not work.

@Overide
public void foo() throws UnsupportedOperationException {
    throw new UnsupportedOperationException();
}

This question concerns Java's design, so I know that it might be hard to answer without one of the people that work on it drops by and answers it, but I was hoping that maybe this question has been asked to them before or that there might be an obvious reason to have it this way to explain why.

Answer 1

One thing which no one has mentioned is a very important answer to your question:

Why throws, on a method, is part of its signature?

that throws, is NOT part of the method signature.

JLS 8.4.2. Method Signature makes it quite clear, that:

Two methods or constructors, M and N, have the same signature if they have the same name, the same type parameters (if any) (§8.4.4), and, after adapting the formal parameter types of N to the type parameters of M, the same formal parameter types.

---

If anyone were to see this method from the outside, they might try to use it without knowing that it is not supported.

That's exactly the main reason, why throws is designed in a way to be checked at compile-time for all Checked Exceptions - clients of the method will be aware what this method may possibly throw.

---

Checked Exceptions are enforced to be either handled or specified to be thrown (but this specification is NOT part of the method signature).

Unchecked Exceptions do not have to be either handled or specified to be thrown, and Oracle's tutorial are good at explaining - why:

Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.