Ramya Subraamanian wrote:I have come across these..
nick woodward wrote:Also, I assume that anything that has to be evaluated to effect control flow cannot cause a statement to be unreachable, because the compiler cannot know the result.
nick woodward wrote:Are there any good resources or example of more complex or tricky code that is/is not unreachable?
the others i would've got i reckon
have you passed your exam?
i'll post some more when/if i find any good ones
Ramya Subraamanian wrote:I have come across these..
Ramya Subraamanian wrote:
i'll post some more when/if i find any good ones
Sure, it would be useful for the exam
Ramya Subraamanian wrote:What am I missing here...or was it some other scenario.
The following statement results in a compile-time error:
while (false) { x=3; }
because the statement x=3; is not reachable; but the superficially similar case:
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.
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.
Ramya Subraamanian wrote:This snippet below wouldnt compile because the compiler doesnt know that i<1 (like (while<true)) would result in a endless loop as i is not a compile time constant.so compiler asks for the return statement.
Ramya Subraamanian wrote:line 1 and line 2 in my code below compiles ,but it is dead code. Compiler doesnt complain line 3 is dead code, but it does compile. and I thought if(false) is similar to having if(<compile time constant boolean value>).What am I missing here...or was it some other scenario.
nick woodward wrote:also, to add to that while(false) explanation - i don't think that x=3 is technically the problem.
while(false){} results in a compile-time error due to unreachable code, even though there is no code that is unreachable.
nick woodward wrote:so an infinite loop negates the need for a return statement? (as long as the compiler knows the loop is infinite due to a literal or constant). is there any design reason for this? seems like a strange allowance to make.
I've given a more detailed explanation in this post (included a possible scenario where this could be useful).
nick woodward wrote:i guess i'm struggling slightly with the logic of allowing no return statement, rather than flagging the infinite loop itself as the problem.
no doubt that's down to inexperience on my part, i'm sure there's a use for them.
Ramya Subraamanian wrote:I think you are trying to give a scenario, of what will happen , incase the "if statements were to behave like while statements".
Being Java programmer.
nick woodward wrote:ifs allow unreachable looking code, and the break allows the possibility that 'after loop' can be reached, despite the compiler knowing it's an infinite loop.
by the same logic, if a return type was defined here, it would have to be provided (or an explicit exception thrown)
One of the drawbacks of this approach: besides the interface a developer can do whatever he likes. So one developer might opt to return null when the value is invalid, another one might want to throw a custom (runtime) InvalidValueException, someone else decides to (ab)use the IllegalStateException in this case, and so on. So a (possible) improvement would definitely be to add an AbstractProcessor class
That's why this methods throws a runtime IllegalStateException and because the compiler knows this throw statement will always be executed, it doesn't complain about the missing return statement.
I hope this post gives you some new insights why it would not have been a good idea if the compiler would flag the infinite loop itself as the problem!
Ramya Subraamanian wrote:We could use default or static methods of the interface in java 8. But then again, static or default methods cannot be made final.
Ramya Subraamanian wrote:Yes, it would definitely benefit all of us .Amazed by your effort. Thanks for sharing your experience
It's a pleasure to see superheros taking such an interest in science. And this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|