Re: Question re testing constructor
On 12/6/2011 6:24 PM, Stefan Ram wrote:
Ian Shef<invalid@avoiding.spam> writes:
ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:null-20111206201830
@ram.dialup.fu-berlin.de:
If the Java compiler is so smart at detecting null values,
why does he not also give an error on code like:
(( java.io.PrintStream )null ).println()
?
Short answer: Because the JLS says so. (see the third edition, paragraph
15.16 where it is explained that most casts are handled at run time).
Something similar:
It is difficult for me to forecast an ?unreachable statement? error.
For example, I would have expected such an error for
public class Main
{ public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( "alpha3" );
if( true )return;
java.lang.System.out.println( "beta3" ); }}
, but did *not* get one, however, the compiler knows that the
beta3 statement *is* unreachable, because he does not care to
compile it.
Omitting the ?if( true )? will give an ?unreachable statement?
error.
I think the unreachable statement rules, as well as the definite
assignment rules, juggle three considerations:
1. Have a single definition of what is a compilable Java program,
regardless of what compiler is doing the compiling.
2. Limit the sophistication of the flow analysis the compiler is
required to do.
3. Keep the rules reasonably simple.
There are a lot of special cases that could be detected at compile time,
but that would add to the rules. It could be left up to the compiler,
but then compilers could disagree about whether a given Java program is
valid without any of the compilers involved having an error.
Patricia