Re: Java language and library suggestions
On Jul 20, 4:53 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
Tomas Mikula wrote:
On Jul 20, 3:36 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
Tomas Mikula wrote:
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 someon=
e feels
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 e=
xception
} 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 s=
till
bad)
solution in this case.
@safe
// code that is incorrectly assumed not to throw any exceptio=
n
So even if it's going to be misused, it could eventually rest=
rain
from
worse things.
"could" != "would".
The proposed language feature would be a change to the languag=
e that
would be easy to misuse, might just possibly (if you're right)=
help
ever-so-slightly in some corner cases, in order to save a litt=
le bit
of typing. It doesn't seem like a good tradeoff. Just wr=
ite 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 sh=
ould
never happen by the designer of the calling code.
The designer of the API may as well state that the declared excep=
tion
will only be thrown under certain circumstances. If I avoided the=
se
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 th=
e
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.
I don't think "the declaration of the argument is probably just
a few lines above" is a good argument in software development.
Substitute 1-10 for "a few" and omit "probably" and it is a good
argument for me.
Consider the example:
int i=8;
double d=1;
String s=null;
// now the following code is necessary, because I don't want to rely
// on the assumption that i==8
if(i!=8){
// handle the exceptional state when i!=8
}
If the logic you are implementing has a special case for
i!=8, then you most certainly should put the code
there.
But right after that I need to check that d is still 1 and s is still
null. But I have already written too many lines since I last checked
that i==8, so I need to check this again...
The decision was made that i was a plain int and not
a final static int.
Yes because that int will be changing somewhere down the code.
It seems obvious to me that you should implement
the complete logic of whatever you are coding.
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.
No no.
He is not changing anything.
He gave you an API where he said that he might throw an
exception.
And he also said (in the documentation) that he won't throw any other
exception than that thrown from the provided Writer.
Java Doc usually documents current implementation.
You should not consider it binding for the future.
(at least not unless it is very controlled code)
You decided to code against his implementation instead
of the API he gave you.
He changed the implementation without changing the API.
Your code broke.
You violated the rules of encapsulation.
He was doing good OOP.
And you can't avoid this risk of changing semantics with almost
anything.
Maybe not. But in this case the API actually provides the
information that it may throw an exception.
The fact that some information may be missing is not a good
argument to ignore the information provided.
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.)
In this case the JDBC specification says that the implementation
must do that, so that it is not up to the implementer whether
what he does.
It can still be argued that it is good to do it explicit,
because the implementation may have an error.
It would still be an error in the implementation, but
defensive programming is good.
Is it bad to rely on String.length() to return no=
n-negative
value? The String.length's API specifies that it returns int. It does
not say anything about the particular value of returned int.
No, but it has to return the length. Length can not be negative.
So a correct implementation will always return an int >= 0.
Math.abs(int) has to return the absolute value. Absolute value cannot
be negative.
One would think that a correct implementation will always return an
int >= 0.
Yet it returns negative value for Integer.MIN_VALUE.
If Math.abs() can return negative value, so could String.length().
Nonsense.
The fact Math.abs(Integer.MIN_VALUE) returns Integer.MIN_VALUE (for
obvious reasons) does not by magic invent strings of negative
length.
There might be some "obvious" reason for length() to return negative
value for some corner case. You just don't find it obvious for the
first time.
(By some lucky coincidence there is no corner case for String.length
().)
> =
But
if the documentation of String.length() says it won't return negative
value, I will trust it, as well as I will trust the documentation of
WriterEncoder.writeEncoded() that it won't throw any IOException other
than propagated from the provided Writer.
Summarized:
- it doesn't do the first assumption
It does.
- you do the second kind of assumptions all the time
1) That does not make it good.
Nor bad.
No it is bad because of the risk of producing unexpected
behavior later.
2) And it is hopefully very rare that such blatant violations of
OOP encapsulation are done
It's not a violation fo encapsulation. It's relying on the specified
semantics.
The only enforced semantics is the fact that the code clearly
states that it may throw an exception.
We already talked about this. I'm going to repeat that the only
enforced semantics of String.length() is that it returns int.
Tomas