• Post Reply Bookmark Topic Watch Topic
  • New Topic

Conditional Compiled Code  RSS feed

 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
NO COMPILER ERROR :




COMPILER ERROR :



why ?
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In addition , I have a doubt regarding the behaviour of the following code snippets too :

CODE A : 
Here, since 'if' is always true and determined at compile time itself, we know for sure that c and d will be initialized before its use . so it compiles fine. but when if is false i.e. if(false) will give an error since c and d will be used without initialization .






CODE B :

Similarly, over here at compile time, we know that if is true and so surely the return statement will get executed,similar to the above example. but yet, it shows an error and expects a return statement outside the if block too. 




why are both the codes contradicting ?
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
anybody with some answer please ?
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.7
It is a compile-time error if a static initializer cannot complete normally (§14.21).


https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.21
A break, continue, return, or throw statement cannot complete normally.

An if-then statement can complete normally iff it is reachable.

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:and then write code such as:
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A break, continue, return, or throw statement cannot complete normally.

what is meant by this ?
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's just terminology that the JLS uses.

When a statement completes normally, execution moves on to the following statement. The break, continue, return and throw statements don't compete normally, execution jumps to a different place.
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi sham wrote:In addition , I have a doubt regarding the behaviour of the following code snippets too :

CODE A : 
Here, since 'if' is always true and determined at compile time itself, we know for sure that c and d will be initialized before its use . so it compiles fine. but when if is false i.e. if(false) will give an error since c and d will be used without initialization .






CODE B :

Similarly, over here at compile time, we know that if is true and so surely the return statement will get executed,similar to the above example. but yet, it shows an error and expects a return statement outside the if block too. 




why are both the codes contradicting ?


Ok. but I don't think that answers my question in this post quoted. My doubt is : in code A, since 'if' is true is already known,  we know for sure that c and d will be initialized before its use. hence, initialization of c and d is not required after the 'if' block too. so it compiles fine. but when if is false i.e. if(false) will give an error since c and d will be used without initialization .

But a similar explanation for code B doesn't hold true, because even though in code B, 'if' is known to be true always and hence will surely execute the return, it expects a return outside the 'if' too . why ?
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Local variables must have definite assignments before they are accessed, and those rules are different from the ones about normal completion.

https://docs.oracle.com/javase/specs/jls/se8/html/jls-16.html
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't see the rules for normal completion. what are those rules about normal completion especially the return statement. I don't seem to find them
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.7
If a method is declared to have a return type, then a compile-time error occurs if the body of the method can complete normally (§14.1).
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have lots of these questions, it may be worth your time to learn how to navigate the JLS. Even though it's technical, it is well written and has many links between related paragraphs.
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.7
If a method is declared to have a return type, then a compile-time error occurs if the body of the method can complete normally (§14.1).


so despite the 'if' being true always, the compiler looks at the path in the method outside the 'if' and doesn't find an abrupt completion ..... and hence , the error 
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:If you have lots of these questions, it may be worth your time to learn how to navigate the JLS. Even though it's technical, it is well written and has many links between related paragraphs.


The JLS is indeed such a vast ocean of many unpredictable facts !   
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi sham wrote:so despite the 'if' being true always, the compiler looks at the path in the method outside the 'if' and doesn't find an abrupt completion ..... and hence , the error 

Exactly. I'm actually not sure why they chose to use one set of rules to determine where methods terminate, and another set of rules to determine where variables have a definite assignment.
 
Stephan van Hulst
Saloon Keeper
Posts: 7976
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have a cow for spotting this inconsistency!
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for all responses and the cow stephan ! 
 
Arco Brouwer
Ranch Hand
Posts: 44
2
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi sham wrote:In addition , I have a doubt regarding the behaviour of the following code snippets too :

CODE A : 
Here, since 'if' is always true and determined at compile time itself, we know for sure that c and d will be initialized before its use . so it compiles fine. but when if is false i.e. if(false) will give an error since c and d will be used without initialization .

CODE B :
Similarly, over here at compile time, we know that if is true and so surely the return statement will get executed,similar to the above example. but yet, it shows an error and expects a return statement outside the if block too. 


why are both the codes contradicting ?

Although it looks inconsistent, I think there is a major difference between these code snippets. The method at A is declared without a return type and the method at B is declared with a return type. Yes, the if-statement at code B will always return to true, but Java double-checks that a valid return type can be reached and assumes that an if statement can always result in true or false. Although this might be inconsistent (and it maybe is), in my opinion it is great that Java is this strict, because it will avoid a lot of mistakes. For code A it is less an issue because no value needs to be returned. In this case it doesnt matter whether or not the code inside if statement will be reached.
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arco Brouwer wrote:For code A it is less an issue because no value needs to be returned. In this case it doesnt matter whether or not the code inside if statement will be reached.

I disagree! It definitely makes a difference that the code inside the if statement is reached. Local variables must be initialized before their usage. So if the code inside the if statement is not reached (e.g. change true to false), code snippet A will not compile.
 
Arco Brouwer
Ranch Hand
Posts: 44
2
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:It definitely makes a difference that the code inside the if statement is reached. Local variables must be initialized before their usage.


Agree with that! I was mainly talking about the return statements since the java compiler expects a return statement when you declare a return type doesn't it?
And indeed, the variables in example A needs to be initialized before they are getting used by the System.out.println statement, otherwise the code will not compile.
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arco Brouwer wrote:I was mainly talking about the return statements since the java compiler expects a return statement when you declare a return type doesn't it?

If you declare a return type, the compiler expects that there is an outcome for each possible branch. But it's not required to be a return statement. This code snippet will compile successfully
 
Arco Brouwer
Ranch Hand
Posts: 44
2
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That looks like something they could trick you on on an exam (if it's not too advanced for OCA).
So a throw statement is a valid outcome for an 'voidless' method. Are you aware of more possibilities?
 
blossom belle
Ranch Hand
Posts: 145
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arco ,

1. If a method is declared to have a return type, then a compile-time error occurs if the body of the method can complete normally (§14.1).

2. A break, continue, return, or throw statement cannot complete normally.

I feel these two statements from the JLS would help in having a better idea about the other possibilities .
 
Arco Brouwer
Ranch Hand
Posts: 44
2
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shambhavi sham wrote:2. A break, continue, return, or throw statement cannot complete normally.

Am I right when saying that a break and continue can only exists within a loop (break/continue) or switch (break only)?
That will leave the return and throw statement available to end a method with a return type.
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arco Brouwer wrote:So a throw statement is a valid outcome for an 'voidless' method. Are you aware of more possibilities?

Not really! But sometimes weird (or "fun") things might happen...
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I would like to add this !

instead of 'if' , while statement will not show the error and does not require return 0; outside the while loop too !
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!