Re: Java language and library suggestions
On Jul 20, 1:43 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
Tom Anderson wrote:
On Sun, 19 Jul 2009, Arne Vajh?j wrote:
Tomas Mikula wrote:
On Jul 19, 3:42 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
Tom Anderson wrote:
On Sun, 19 Jul 2009, Lew wrote:
Tomas Mikula wrote:
Anyway there are still many cases when one could use safely it
to get
more readable code.
Arne Vajh?j wrote:
It can happen, but I don't think it occur frequently enough to
justify a feature that is so easy to misuse.
Tomas Mikula wrote:
I disagree again. Almost everything can be misused. If someone fe=
els
like their code never throws an exception, they could tend to
write an
empty exception handler:
try {
// code that is incorrectly assumed not to throw any excep=
tion
} catch(Exception e) { }
If the Exception can actually be thrown and should be handled,
this is
very bad.
I guess that the following would be a much better (although still
bad)
solution in this case.
@safe
// code that is incorrectly assumed not to throw any exception
So even if it's going to be misused, it could eventually restrain
from
worse things.
"could" != "would".
The proposed language feature would be a change to the language th=
at
would be easy to misuse, might just possibly (if you're right) hel=
p
ever-so-slightly in some corner cases, in order to save a little b=
it
of typing. It doesn't seem like a good tradeoff. Just write =
the
damn
exception handler and quit complaining.
This *is* an exception handler! It's shorthand for:
try {
STATEMENT
}
catch (EXCEPTION e) {
throw new AssertionError(e);
}
How is that not an exception handler?
It is an exception handler.
But it is converting the exception that the designer of the API
being called consider a real possibility to an exception that should
never happen by the designer of the calling code.
The designer of the API may as well state that the declared exception
will only be thrown under certain circumstances. If I avoided these
circumstances, then the exception won't be thrown. I will provide an
example:
class WriterEncoder {
public WriterEncoder(Writer w);
/** @throws IOException if and only if the write() methods of
underlying Writer throw an exception. */
public void writeEncoded(MyClass obj) throws IOException;
}
Now if I construct the WriterEncoder with StringWriter which does not
throw IOException on write, I can be sure that
WriterEncoder.writeEncoded() won't throw IOException either.
Yes.
But it is very bad code.
The safe construct is relying on knowledge about implementation of
both the calling and the called code instead of just relying on the
exposed API's.
But this is complete nonsense! That example DOES only rely on the
exposed APIs!
No.
It relies on:
1) that it is indeed a StringWriter and not another writer that gets
passed in as argument
The very same method that uses @Safe passed StringWriter to the
constructor of WriterEncoder just a couple of lines before. So the
method is only relying on itself.
2) that writeEncoded only throws IOException if the passed Writer
throws IOException.
Bad code.
WriterEncoder.writeEncoded's API specifies that it throws the same
checked exceptions as the writer's write method.
No it does not.
WriterEncoder.writeEncoded's API specifies that it
throw IOException. It does not say anything about
when it does it.
The API can't fully express the semantics.
If the semantics of WriterEncoder changes without generating compiler
warning or error, that is a bad decision of the WriterEncoder
designer.
And you can't avoid this risk of changing semantics with almost
anything. You rely on the documentation all the time. For example, is
it a bad practice to rely on java.sql.Statement.close() to close
associated ResultSet? (I guess you will say yes, so I provide another
example.) Is it bad to rely on String.length() to return non-negative
value? The String.length's API specifies that it returns int. It does
not say anything about the particular value of returned int.
StringWriter.write
declares that it throws no checked exceptions. Therefore, if you use
WriterEncoder.writeEncoded with a StringWriter,
But the day the code is changed to pass another Writer, then
the code still compiles fine, but the code is broken.
As usual happens when coding to implementation instead of
interface.
=
you are permitted to
conclude that it won't throw any checked exceptions. That is not bad
code, and it is not relying on knowledge of implementation details.
It is bad code, because it makes two assumptions about
implementation.
Summarized:
- it doesn't do the first assumption
- you do the second kind of assumptions all the time
Tomas