Re: Why does Java require the throws clause? Good or bad language
design?
Robbert Haarman wrote:
Yes, of course. If you write the code, you can write whatever you want,
including code that never throws any exceptions at all. However, that is
not the situation I was referring to. I meant the case where you use an
existing method which could throw an exception.
For example, and I apologize in advance if I don't get the details
exactly right, if you were to write a program that read a file and wrote
its contents to standard output, you could write the following:
public void passThroughStream(InputStream is, OutputStream os) {
// some code to read from the input stream and write to
// the output stream, which could throw IOException
}
public void passThroughFile(String name, OutputStream os) {
// open the file and call passThroughStream
}
public static void main(String args[]) {
passThroughFile(args[0], System.out);
}
However, this code would not work, because the IOException is not
handled. If you want the exception to propagate up the call chain and
eventually abort the program with an error message, you would need to
add throws clauses to both passThrough* methods, and a try ... catch
block to main, or convert the IOException to an unchecked exception;
precisely as I said.
But this is not a Java issue, it is a design issue with the method that
declares that it throws the IOException. That is something that the designer
of that method put in for a reason. Mainly, it alerts you at compile time that
you have handled those things in the method that can be handled, or not.
That is a good thing, for that method with that particular exception. It is
the API designer's way of helping you. It says nothing about whether checked
exceptions /per se/ are a good thing, unless you agree with me that this
particular use actually helps the user of the API and that therefore the fact
that Java allowed the API designer to do it is also a good thing.
Discussion of whether checked exceptions are a "good" or "bad" feature of Java
does not depend on how one specific API call uses the feature, but on whether
the feature helps programmers and fails to hinder them.
As to whether a particular checked exception is "good" or "bad" for, say, a
Reader.read() call, that is a different matter. I think that the declaration
in the throws clause really helps the API consumer to be thorough in handling
what can go wrong.
In any event, just because one particular method uses a throws clause doesn't
make the throws clause itself mandatory in the language. It is a feature that
some programmer chose to use, just like you can when it's your API to write.
- Lew