Re: [coding practises] do you declare your superclass "throws"??
Lew wrote - actually, he didn't, he pressed SEND first.
Sorry about the accidental SEND before replying. Please disregard that.
Andreas Leitgeb wrote:
Otoh, if rather than commenting stuff out I prepend it with "if (false)",
then the code is still dead, and the compiler doesn't even write a
warning.
If it did, it would violate the JLS.
But "if (false)"ing is still no substitute, since it still requires
the thusly deaktivated part to still be compileable.
But not necessarily compiled. Anyway, the whole point of that section is to
lock down one type of incorrect code. You guys are arguing that Java should
be more tolerant of that variety of incorrect code. Java is saying, "Tough
noogies." I'm agreeing with Java. Having a compiler call bad code an error
is not the worst flaw in the Java language.
Also, I just tried: unused private methods do *not even* raise
a warning in javac (this seems to be an eclipse-feature). I consider
Good point. It should. Java should be more strict, not more lax.
unused private methods to be the principially same thing as unused
default-blocks in exhaustive switches and catches for unthrown
exceptions. Actually, if/while-statement-bodies, whose condition
can be determined as always-false could also be determined as
dead code, but only if the consequence were not worse than a warning,
since that's probably the most-used workaround for the annoying
feature under discussion.
There is a difference in the language spec between how conditions are handled
in if statements and how they're handled in while statements.
I'd find it reasonable that all of them threw warnings.
The Java designers went through a great deal of trouble to define if (false)
to allow conditional non-compilation without it being an error.
JLS
<http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.21>
/op. cit./ upthread:
if (false) { x=3; }
does not result in a compile-time error.
An optimizing compiler may realize that the statement
x=3; will never be executed and may choose to omit the code for that
statement from the generated class file, but the statement x=3; is
not regarded as "unreachable" in the technical sense specified here.
I'm not entirely sure I read your message correctly, but it seemed to take
issue with that feature.
--
Lew