Home > Archive > Java Help > February 2007 > Re: Why does Java require the throws clause? Good or bad language
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Why does Java require the throws clause? Good or bad language
|
|
|
| Chris Smith wrote:
> To understand this bit of language design, you need to get your head
> around the fact that declaring methods isn't some boilerplate thing that
> you do because the compiler makes you. A method declaration is a
> contract with a caller, and the fact that certain errors can be
> generated is part of that contract. ...
Java is one of the languages for those times when static checking and other
"big iron" scaffolding are the order of the day. It is well suited to
"development by contract", a possible term for the methodology Chris described
so eloquently.
It is natural that Java feels a little stuffy at times, but the formality
serves the goals of system robustness, correctness, adaptability and
longevity. I think of Java as "industrial strength", "big bore", perhaps
"armored". These are good things, especially given that Java accomplishes
these things with, all things considered, a reasonably "light" language flavor
overall.
Chris showed how a certain thought process is compatible with what Java offers
for exception declaration semantics. Use these arguably ponderous idioms for
their intended value and you may come to appreciate their solidity.
- Lew
| |
|
| Robbert Haarman wrote:
> In particular, if you want the commonly useful behavior that any
> exception should propagate up the call chain until it is handled, and if
> it is not handled otherwise, the program should abort with an error
> message, you still have to write "throws Exception" and a try ... catch
> block (or, alternatively, convert checked exceptions to unchecked
> exceptions at some point).
Not true. If you want to throw an exception that behaves as you describe,
simply throw an unchecked exception and handle it farther up the chain, just
as you say you want. No "mandatory throws clause" needed.
Of course, then you sacrifice the benefits of checked exceptions, but that is
your absolute right as a designer.
If someone else wrote a method with a checked exception that you want to use,
then that programmer is the one requiring you to handle the exception, not
Java, the language itself. That means that that programmer thought about their
API and decided that the exception was important enough to warrant mandatory
handling on the part of all the API's consumers.
Don't blame the language for the programmer's decision. They could have used
an unchecked exception but chose instead to declare a checked one. That is the
power of choice that Java gave them.
- Lew
| |
|
| 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
|
|
|
|
|