• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Why no compilation error?

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ranchers,
Please consider the following code...




My question is why are we not getting a compilation error saying "Unreachable statement" citing line 1?

Can somebody please explain?
Thanks in advance.

Uttara Rishi.
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sir, your question is the answer.

"Unreachable statement" citing line 1

'test()' method will throws Error all the time, so System.out.println("test"); is "Unreachable statement"

that is why you got a compilation error.
 
Rancher
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by yu yong:
Sir, your question is the answer.

"Unreachable statement" citing line 1

'test()' method will throws Error all the time, so System.out.println("test"); is "Unreachable statement"

that is why you got a compilation error.



You missed what is arguably the most crucial word in Uttara's post viz., "NOT". Am reproducing what Uttara said below with my own emphasis:


My question is why are we not getting a compilation error saying "Unreachable statement" citing line 1?



In other words, Uttara agrees with you -- he expects a compilation error, doesn't find one, and is surprised why.

Uttara - My own theory is this: Unreachable code is not grounds for an error. It could be a warning though. I expect the JLS does not mandate a diagnostic. One of the gurus can clarify.

As an aside, C and C++ compilers identify unreachable code only when asked to do "code flow analysis" - something they do only when optimization is enabled. See if your Java compiler has some kind of option to enable this warning. Even if it doesn't, IMHO, it only reflects a QoI issue, not a language issue.

- Anand
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Anand]: Even if it doesn't, IMHO, it only reflects a QoI issue, not a language issue.

Actually, details of reachability analysis are specified in the Java Language Specification. Whenever you get an "unreachable code" error, it's because the compiler was required to give you one. And when you don't get one, as in this case, it's because the compiler is forbidden to do so. That's generally true for all compiler errors - Java's creators wanted to avoid the situations of having code that compiles and works on one machine but not another. Of course this doesn't always work out perfectly, but that's the intent.

Specifically in this case, for an if statement, if the if statement itself is reachable, then the "then" clause and the "else" clause are always reachable as well - even if the condition in the if statement is a compile-time constant true or false, which would otherwise allow the compiler to determine conclusively which branch would be taken. This may seem strange, but the reason is given in the JLS:

The rationale for this differing treatment is to allow programmers to define "flag variables" such as:

    static final boolean DEBUG = false;

and then write code such as:

    if (DEBUG) { x=3; }

The idea is that it should be possible to change the value of DEBUG from false to true or from true to false and then compile the code correctly with no other changes to the program text.


If the compiler were to flag the above code as unreachable (even though it is). then that would create a problem for people using this style. In practice, people don't use this style much anymore anyway - instead they usually just rely on a logger with configurable logging levels. But this style was relatively common among C programmers back when Java was being created, and so Java's creators made a special effort to support it.
[ March 12, 2008: Message edited by: Jim Yingst ]
 
Anand Hariharan
Rancher
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:
[Anand]: Even if it doesn't, IMHO, it only reflects a QoI issue, not a language issue.

Actually, details of reachability analysis are specified in the Java Language Specification. Whenever you get an "unreachable code" error, it's because the compiler was required to give you one. And when you don't get one, as in this case, it's because the compiler is forbidden to do so.


Appreciate the insights, Jim.

That's generally true for all compiler errors - Java's creators wanted to avoid the situations of having code that compiles and works on one machine but not another. Of course this doesn't always work out perfectly, but that's the intent.



Now, that would understandably be the goal of any language, wouldn't it?

My statement regarding QoI was based on my theory that it should be a warning rather than an error. If a warning shows up in one compiler and not the other, methinks it is reasonable to consider it a QoI issue (e.g., a compiler could presumably warn about a variable name not conforming to some standard guideline). Of course, I did err in assuming that it should be a warning.

thanks once again,
- Anand
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

One more theory (obviously mine ) says that java compiler cannot check what is stored inside a variable. Thus the compiler doesn't know the meaning of true or false. It even doesn't know the meaning of 1's and 2's that we assign to integers in our code.

Moreover, if it were able to know, then there would'nt have been a need to develop a java runtime (what we call the 'java.exe').

Thus, if there is any logical branching going on inside a code, it will entirely depend on the code that the unreachable code error is thrown or not.

for example : (code written by myself)



This code will surely give unreachable code error.
 
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,


First of all good discussion,putting in lot of thoughts thats good

ok now coming to the actual question.

their is no unreachable error at line1 because in the previous line you are throwing an error which comes into picture only at runtime. So it clearly goes unnoticed by compiler. Hence no unreachable code error.

Generally when you have break,continue or conditions which can be evaluated at compile time only unreachable code occurs.

Try throwing an exception at line1 you will get the unreacable code error. Because compiler knows that by explicitly throwing an exception the very next statement will never be executed.

Hope this helps
 
Anand Hariharan
Rancher
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rohit and Srinivas -

Please take a moment to go through the link that Jim posted. There is a lot to take in and process, I admit, but the JLS definitively has the last word on this issue.

When you have compile time constants (such as boolean literals 'true' and 'false', integer literals such as '1' and '0'), the compiler is most certainly aware (and can take advantage) of them. This does not, in any way, take away the role played by the JRE.

There seems to be a contradiction between what you say in the third and fifth paragraphs of your post, Srinivas ("their is no unreachable error at line1 because in the previous line you are throwing an error which comes into picture only at runtime" and "Try throwing an exception at line1 you will get the unreacable code error."). While an error being thrown is certainly a runtime event, keywords such as "throw", "break" and "continue" cause the java compiler to put in "unconditional jumps" in the byte code.

- Anand
 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
look at the code carefully if you are not using brackets the immediate statement take as the if and the next one as the else
 
Anand Hariharan
Rancher
Posts: 280
VI Editor C++ Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hasitha Randika:
look at the code carefully if you are not using brackets the immediate statement take as the if and the next one as the else



That is incorrect. Should the execution flow continue after executing the statement(s) within an if block, the statements following that block are unconditionally executed. They are not implied as 'else' (unless of course, the 'else' keyword appears following the if block).
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You'll get an unreachable code error only if you add an else statement after the if and before line 1 (line 1 should be outside the else statement).This is because the JVM won't check whether the code inside an if statement always executes to true.
 
reply
    Bookmark Topic Watch Topic
  • New Topic