1

Possible Duplicate:
semicolon at end of if statement

I was programming, and found a bug in my code, and it was because of a semi colon after an "if" statement, and its boxy "{ xxx }" was being executed as if it has its own scope -- so everything would get compiled.

This begs the question, why is:

if (x != null);

A possible statement in Java, it seems like a useless line of code that could generate lots of bugs, etc.

Community
  • 1
  • 1
somid3
  • 680
  • 1
  • 7
  • 19
  • 5
    My first guess: elegance of language design. –  Jan 20 '13 at 21:26
  • 1
    Can someone put the _bytecode_ for this? – Paul Vargas Jan 20 '13 at 21:28
  • 1
    @PaulVargas: this might actually compile into the empty program, if the compiler's analyzer is smart enough. –  Jan 20 '13 at 21:29
  • 2
    check out the answer on [this question](http://stackoverflow.com/a/14112532/1904979) (which is exactly the same as the question asked here) – Peter Elliott Jan 20 '13 at 21:29
  • 1
    For people that use one liner if statements? if not null do nothing. I put the { on the same line as the if conditional to prevent this from happening. `if (x != null) {;` – dting Jan 20 '13 at 21:30
  • Also note that allowing `while (x.next() != null);` but forbidding `if (x.next() != null);` would be too arbitrary of a choice. –  Jan 20 '13 at 21:31
  • `javap -c` to see bytecode. `javac` has had the little optimisation code it did have because it added complication without being of much benefit to code which was going to get compiled into machine code anyway. – Tom Hawtin - tackline Jan 20 '13 at 21:31
  • Because an empty statement is a legal statement, detecting that it might cause an error in this case would cost time and effort. Quoting Eric Lippert (http://blogs.msdn.com/b/ericlippert/archive/2012/04/03/10251901.aspx). "I'm often asked why the compiler does not implement this feature or that feature, and of course the answer is always the same: because no one implemented it. Features start off as unimplemented and only become implemented when people spend effort implementing them: no effort, no feature." – tvanfosson Jan 20 '13 at 21:32
  • compiler are compiler... not truly inteligent ;-) syntax are ok... not always can check if the code are logic... change "if" by "while" and you have spinup wait/"sleep"... "while (x!=null);" – ggrandes Jan 20 '13 at 21:32
  • @Tinctorius, disagree with `while` versus `if`. `if (x.next() != null);` is `x.next();`, but that doesn't hold for `while`. Also I just checked, Eclipse doesn't even throw a warning at me for @somid3's line. I think a warning would be absolutely appropriate. – s.bandara Jan 20 '13 at 21:33
  • 1
    @s.bandara: I think you misunderstand the purpose of my example. I know they are not equal. The thing is that both `if` and `while` have a similar syntactical structure, and to forbid the empty statement in `if` but not in `while` would be very arbitrary (and very awkward) from a language design perspective. –  Jan 20 '13 at 21:38
  • 2
    If someone cares, I actually ran it through `javac` and `javap -c` --- and the `null` check is there: `0: aload_0 1: ifnull 4 4: return` – Marko Topolnik Jan 20 '13 at 21:41
  • @Tinctorius, now I see your point. Makes a lot of sense in terms of language structure. Thanks. – s.bandara Jan 20 '13 at 21:41

2 Answers2

3

That line is essentially equivalent to:

if (x != null) {
}

You can, however, create a line like:

if (x != null) System.out.println(x);

So it exists to support that kind of execution of code, but your example is just shorthand of my first example.

Marc Baumbach
  • 10,323
  • 2
  • 30
  • 45
  • right, but that is a completely useless if statement... that's exactly my point, why would you ever do an if statement the way you wrote it? – somid3 Jan 20 '13 at 21:38
  • Well, as others have mentioned, sometimes compilers are optimized such that weird situations like this are possible, even though undesired. Usually the best way to get around bugs like this are to have various static analysis tools which can look for problems like unnecessary code. Unfortunately, I think this is just one of those areas where the language allows you to fall on your own sword if you aren't careful. Every language has them. :) – Marc Baumbach Jan 20 '13 at 21:42
0

From what I can see (I may be wrong) there's only one reason to do something like this.

Imagine x is a getter, and then getting the variable x from the current class, you execute another piece of code (or maybe just cache the response of x).

That said, if that's the case, I think that x; would work just as well.

h2ooooooo
  • 39,111
  • 8
  • 68
  • 102
  • yeah, that's exactly what I mean, the compiler should throw an error saying "unresolved if statement" or something, after all there are other exceptions that are thrown in similar situations such as "unexecutable code", etc. – somid3 Jan 20 '13 at 21:36