tags:

views:

376

answers:

5

I'm kinda waiting for a 'no' answer on this question.

I was interested if you can save a variable at the same time when you checking it in an if-clause.

Let's say I have this code.

if(foo!=null){
  if(foo.getBar()!=null){
    Bar bar = foo.getBar();
    System.out.println("Success: " + bar);
  } else {
    System.out.println("Failure.");
  }
} else {
  System.out.println("Failure.");
}

I handling now to "failure" -states independently, even if the outcome is the same. I could get them together like this:

if(foo!=null && foo.getBar()!=null){
  Bar bar = foo.getBar();
  System.out.println("Success: " + bar);
} else {
  System.out.println("Failure.");
}

Much neater code already. if foo is null it will stop there and won't try foo.getBar (in the if) so I won't get a NPE. The last thing i would like to enhance, and the main question: Do I really gave to call on foo.getBar() twice? It would be nice to get away from the second identical call if getBar() would be a very heavy operation. So I am wondering if there is somehow possible to do something similiar to this:

if(foo!=null && (Bar bar = foo.getBar())!=null){
  Bar bar = foo.getBar();
  System.out.println("Success: " + bar);
} else {
  System.out.println("Failure.");
}

I would have to break it up to two different if's again if I would like to do

Bar bar = foo.getBar();
if (bar!=null) ...
+3  A: 

I have used that technique when iterating over lines from a BufferedReader:

BufferedReader br = // create reader
String line
while ((line = br.readLine()) != null) {
    // process the line
}

So yes, you can do an assignment, and the result off that will be the left hand side variable, which you can then check. However, it's not legal to declare variables inside a test, as they would then only be scoped to that expression.

Staale
+9  A: 

This is the closest you can get:

Bar bar;
if(foo!=null && (bar = foo.getBar())!=null){
  System.out.println("Success: " + bar);
} else {
  System.out.println("Failiure.");
}
Michael Borgwardt
Yeah, this actually worked. I tried to have (Bar bar = foo.getBar()) !=null inside the if, but java doesn't seem to like to have the Object's initialization inside the if-clause. Thanks!
Jens Jansson
+2  A: 
TofuBeer
A: 

From the department "My Programming Language is Better Than Your Programming Language": In Groovy, you can use the "?." operator:

Bar bar = foo?.bar
if (bar != null) {
}

In Java, this is good pattern(*):

Bar bar = foo == null ? null : foo.getBar();
if (bar != null) {
}

*: Something you can save in your fingertips.

Aaron Digulla
+1  A: 

Three points that completely fail to answer the question:

null is evil. Don't write methods that return it. Your example problem would then disappear.

I think you might be missing out on encapsulation. Instead of foo.getBar() could the interface of foo be made such that you perform a "tell don't ask" operation?

Side-effects in expression tends to cause bad code. Prefer more, simpler lines to fewer, buggy lines. The usual exception if using ++ to increment an index when accessing a buffer, or similar iterator style algorithms.

Tom Hawtin - tackline