lect04a
Nesting if-else; connectives

An alternative to nesting: `if`-`else`-`if`

We saw last time that you can nest an if-else statment inside another else clause. The need for this is actually very common; it happens whenever we need to choose between more than two equal options. While what we wrote makes sense, it's annoying for two reasons:

If we have seventeen equal options we're choosing between, our code will “rightward drift” right off the screen.
More disturbingly, our code won't reflect how we think about the problem: if all seventeen options are equally important, why should some options contain the others, just because we consider them in some particular order? (“last” does not have to mean “least”!)

In response to these common concerns, Java includes a variant of the if-else statement, call the if-else-if statement. Here's an example:

/** Return a greeting, selected randomly from a list of several greetings.
 * @return A greeting (randomly selected, not necessarily uniformly).
 */
String greet() {
  int choice = (new java.util.Random()).nextInt(100);
  // We'll discuss the "new" statement later¹; here's the upshot: the local variable 
  // 'choice' now stores a number in the interval [0,99], a.k.a. [0,100).
  
  if (choice < 30) {
    return "Hello.";
    }
  else if (choice < 33) {  
    return "Aloha.";
    }
  else if (choice < 50) {  
    return "Buenos dias, amigo/amiga.";
    }
  else if (choice < 99) {  
    return "Yo.";
    }
  else if (choice < 100) {  
    // Not an advisable greeting.  Use sparingly.
    return "I am a javabot: System dot out dot println open \"hello\" close.";
    }
  else {
    System.err.println( "This statement is unreachable (I hope)." );
    return "A dummy return-statement to satisfy the compiler";
    }


  // Is this line ever reached?  Why or why not?

  }

Some discussions:

The return statement means “stop this function right now, and return an answer”. Thus ² the line at the end will never actually be reached, because one of the return statements will be selected first.
If choice is initialized with the value 30, what number is returned? How about 34?
What is the probability of returning Hello? How about Aloha? Half-open intervals make this answer easy (no having to decide whether add one or to subtract one)!
Is the choice < 100 branch actually ever taken?
What if we change “< 100” to “<= 100”?
What if we change “< 99” to “<= 99”?
If we leave off the “appeasing” return statement, the program doesn't compile; java complains “possible to reach end of function without a return statement”. Why? Discuss.
More fundamentally: Should the if (choice < 100) be omitted, so that it is the catch-all else? Consider—what if we have some mistake in our series of cases (say, accidentally leaving off the case, for some intermediate range of numbers)? Can the compiler catch such a mistake automatically?
guideline: If your last condition is easy to phrase (as it is here), then certainly include it, making the last else unreachable. But don't bend over backwards, to do this; sometimes formulating that final condition is more error-prone than the savings you'd get!

Note: Mention: Some teachers don't like having more than a single return statement inside a function, since it can be confusing to look at the middle of some code and not realize that in many circumstances that code will never be reached. Note that using our discipline of “if one branch of an if-else-if returns, then every branch should return” obviates that complaint (though you might encounter teachers who ).

Well, new is nothing too magical; it creates a particular instance of a class. In this case, the class isn't “PizzaServer” but “java.util.Random” (a longwinded name, indeed). And instances of this class can't be asked about pizzaArea, but they do know how to generate a nextInt randomly.

So far we have been making new instances in BlueJ by right-clicking on “new PizzaServer()” (or whatever our class is named), but “new” is actual Java code to do the same thing. Note that we could have even named this java.util.Random instance with a local variable, if we had wanted to:

    java.util.Random ro = new java.util.Random();
    int choice = ro.nextInt(100);

We'll talk more about new and local-variables-to-hold-instances in the following weeks, but all the fundamental concepts are in place!

↩

² So we could conceivably use a series of if statements (without else), rather than a big if-else. The second if statement is only reached when the first condition wasn't true (because in that case we'd return before ever reaching the second if condition). ↩

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2007, Ian Barland, Radford University
Last modified 2007.Sep.16 (Sun) Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu

lect04aNesting if-else; connectives

An alternative to nesting: if-else-if

lect04a
Nesting if-else; connectives

An alternative to nesting: `if`-`else`-`if`