Why does Java require the throws clause? Good or bad language design?

[John W. Kennedy]

There are perfectly valid engineering reasons for wrapping exceptions
and rethrowing them as custom exceptions, or eating the exception and
converting to a non-exceptional value. It has to do with calling classes
not caring any more what the original exception is, if it was logged at
the lowest point, but only that an application-level exception occurred,
or no exception if the called method ate it.

Another reason to rethrow just came up for me yesterday, involving
parsing a complex CSV file.

In parse-field routine, throw MyFieldSyntaxException
In parse-record routine, catch MyFieldSyntaxException and
throw MyRecordSyntaxException, identifying the field
being processed at the time.
In read-file routine, catch MyRecordSyntaxException and
throw MyFileSyntaxException, identifying the record
being processed at the time.
In main method, catch MyFileSyntaxException, and give
the user all the bubbled-up information to diagnose the
problem.

The alternate approach would be to pass "where am I?" information all
the way down to the "parse-field" routine, information that that routine
has no use for unless it needs to construct the exception -- and that
scheme immediately breaks down if, say, the parse-field routine must
later be applied to a VARCHAR column of an SQL database.

 

[Chris Smith]

It's is exposing a failure mode to aaa() despite the fact that neither it nor
aaa() necessarily have any interest in that failure mode. Consider the earlier
example of a file-backed implementation of java.util.List.

Ah! It took an example with more meaning to get me to see what you're
talking about. Yes, it's certainly a good idea to be able to create a
file-backed List, and it does require additional language extensions.
Perhaps something like (abusing syntax):

interface List <addedExceptions=e>
{
public void put(int index, Object obj)
throws UnsupportedOperationException, e
{
...
}

...
}

I was thinking of the more mundane case you mentioned; I think (but am
not sure) that this situation requires run-time polymorphism to arise,
so I didn't see it when the example was just a straight-forward chain of
method calls.

At this point, the syntax is getting a little strange. The callback
case could be handled very cleanly, I thought, assuming that one has
first-class functions beforehand; this seems messier. I'll have to
think it over a bit.

The contract is (should be) between the place where the exception is generated
and the place where the exception is (intended) to be handled.

I think we're talking at cross purposes with all this contract stuff. I
have a very definite idea of what constitutes a "contract" in a software
system, and this doesn't fit it. But I agree with all of your
conclusions, so I now agree it is probably just a matter of vocabulary.

I would say, instead, that the contract between 'put' and its caller
above is parameterized by the type of the object on which 'put' is
called (specifically, by its type parameter e).