Logical Operators, Booleans, and Validating Input

1. Logical Operators, Booleans, and Validating Input

Title

Think Java 2e · Chapter 5 · Conditionals and Logic

Sections 5.5-5.10 · pp. 77-84

2. What you will be able to do

Objectives

This lesson follows Think Java 2e, Chapter 5 (Conditionals and Logic), Sections 5.5-5.10, pp. 77-84. Everything on these slides can be checked against those pages.

1. Combine conditions with &&, || and !, and predict when the second operand is not evaluated.

2. Apply De Morgan's laws to rewrite a negated condition without the exclamation mark.

3. Declare and use a boolean variable as a flag, and say why you never compare one to true.

4. Write a method that returns a boolean, and use it directly as a condition.

5. Validate input for both format and range, and say which run-time error each check prevents.

6. Use return to leave a method early, and System.err for error messages.

• 5.5 — Logical Operators
• 5.6 — De Morgan's Laws
• 5.7 — Boolean Variables
• 5.8 — Boolean Methods
• 5.9 — Validating Input
• 5.10 — Example Program

3. Retrieve before you read

Warm-up

One structure from the previous lesson, which this one is about collapsing.

4. From one condition to real logic

Concept

The previous lesson could test one thing at a time. This one lets you combine conditions, negate them readably, store them, name them, and finally use them to make a program safe against whatever a user types.

• 5.5 — the logical operators, and short-circuit evaluation
• 5.6 — De Morgan's laws for negating a condition
• 5.7 — boolean variables, used as flags
• 5.8 — methods that return a boolean
• 5.9-5.10 — validating input, and the complete program

Downey & Mayfield, Think Java, 2nd edition (Green Tea Press / O'Reilly, 2020) — Think Java 2e, Chapter 5 (Conditionals and Logic), Sections 5.5-5.10, pp. 77-84 — Sections 5.5-5.10, printed pages 77-84.

5. Logical operators

Section

Section 5.5

6. and, or, not

Concept

In addition to the relational operators, Java has three logical operators: &&, || and !, which stand for and, or and not. Their results are similar to their meanings in English.

x > 0 && x < 10      // true when x is greater than 0 AND less than 10
x < 0 || x > 10      // true if EITHER condition is true
!(x > 0)             // true if x is NOT greater than 0

logical operator — An operator that combines boolean values and produces a boolean value.

The parentheses in !(x > 0) are necessary, because in the order of operations ! comes before >. Without them Java would try to negate x itself, which is not a boolean.

7. Collapsing nested and chained conditionals

Notation

The two most useful things && and || do are remove a level of nesting and remove a duplicated branch.

Reading a condition aloud is a good test. if (x == 0 && y == 0) reads as if x is zero and y is zero, which is what you meant. The nested version reads as a set of instructions instead.

8. Short-circuit evaluation

Worked example

Logical operators evaluate the second expression only when necessary. That is not merely an optimisation — it changes what code is safe to write.

// true || anything   is always true
// false && anything  is always false

if (count != 0 && total / count > 10) {
    System.out.println("high average");
}

Short-circuit evaluation can save time if the second operand is expensive to compute, and it can avoid unnecessary errors if the second operand might fail.

9. Is the second operand evaluated?

Prediction

Short-circuit evaluation, with a division that would fail.

int count = 0;
int total = 50;
if (count != 0 && total / count > 10) {
    System.out.println("high");
}

10. Precedence among the logical operators

Concept

! binds tightest, then &&, then || — and all of them bind more loosely than the relational operators. That ordering is why most conditions need no parentheses at all.

The second row is the one that bites. Because ! comes before > in the order of operations, !x > 0 tries to negate x — and since x is not a boolean, it does not compile. When negating a comparison, the parentheses are not optional.

11. Writing a range test the way you say it

Trap

if (0 < x < 10) {          // does not compile
    System.out.println("in range");
}

if (0 < x && x < 10) {
    System.out.println("in range");
}

12. Which operator does the job?

Definition probe

Read each requirement in English and choose the operator.

13. Write a range test

Fill the middle

True when x is at least 1 and at most 100.

14. When does the order of operands matter?

Edge cases

Push on short-circuit evaluation until it changes behaviour rather than just speed.

15. De Morgan's laws

Section

Section 5.6

16. Negate each term and change the operator

Concept

Sometimes you need to negate an expression containing a mix of relational and logical operators. Doing it with ! and parentheses produces a condition that is hard to read. De Morgan's laws give a better way.

// hard to read:
if (!(x == 0 || y == 0)) {
    System.out.println("Neither x nor y is zero");
}

// after applying De Morgan:
if (x != 0 && y != 0) {
    System.out.println("Neither x nor y is zero");
}

In words: negating a logical expression is the same as negating each term and changing the operator. The logic is identical and the source code is much easier to read.

17. Negating relational operators

Notation

De Morgan's laws also apply to the relational operators. Negating a term there means using the opposite operator, which is not always the one people reach for.

The practical value is readability. x != 0 && y != 0 can be read aloud and checked; !(x == 0 || y == 0) has to be worked out.

18. Applying the law step by step

Worked example

Negate a two-part condition mechanically rather than by intuition, then check the result against a truth table.

// negate:  age >= 18 && hasTicket
// step 1:  negate each term
// step 2:  change && to ||
// result:  age < 18 || !hasTicket

19. What is the negation?

Prediction

Apply the law mechanically.

// negate this condition:
x > 10 && y < 5

20. Why bother, when ! works?

Concept

!(A && B) is perfectly correct Java. The argument for rewriting it is entirely about the person reading it next.

The last row matters: De Morgan is for compound conditions. A single negated boolean, especially one with a well-chosen name like found or valid, is already as readable as it is going to get.

21. Forgetting to change the operator

Trap

// intended: NOT (in stock AND affordable)
if (!inStock && !affordable) {      // wrong
    System.out.println("cannot buy");
}

// NOT (inStock && affordable)  ->  !inStock || !affordable
if (!inStock || !affordable) {
    System.out.println("cannot buy");
}

22. Match each condition to its negation

Matching

Four negations, done correctly.

23. Which negation is wrong?

Elimination

Three of these apply the law correctly.

24. Say De Morgan's law in English

Explain it to yourself

Without symbols.

25. Boolean variables and flags

Section

Section 5.7

26. Store a true or false value in a variable

Concept

To store a true or false value you need a boolean variable. You declare and assign them like any other variable — and since relational and logical operators evaluate to a boolean, you can store the result of a comparison.

boolean flag;
flag = true;
boolean testResult = false;

boolean evenFlag = (x % 2 == 0);     // true if x is even
boolean positiveFlag = (x > 0);      // true if x is positive

flag — A variable, usually boolean, that represents a condition or status.

A variable defined this way is called a flag, because it signals — flags — the presence or absence of a condition. The parentheses around the comparison are unnecessary, but they make the code easier to understand.

27. A flag is a condition you have named

Picture it

The value stored is exactly what the condition evaluated to. Naming it means the test can be done in one place and used in several.

Flags may not seem that useful yet. They will help simplify complex conditions later: each part of a condition can be stored in a separate flag, and those flags combined with logical operators.

28. Never compare a boolean to true

Worked example

Since a boolean variable already is a condition, testing it against true adds words and takes meaning away.

boolean evenFlag = (x % 2 == 0);

if (evenFlag) {                    // good
    System.out.println("n was even when I checked it");
}

if (!evenFlag) {                   // good — to check for false
    System.out.println("n was odd when I checked it");
}

29. What does this print?

Prediction

A flag holding the result of a comparison.

int x = 7;
boolean isEven = (x % 2 == 0);
if (!isEven) {
    System.out.println("odd");
} else {
    System.out.println("even");
}

30. Naming a flag well

Concept

A flag's whole value is its name. A well-named one makes a condition read as a claim about the program's state.

The last row is worth dwelling on. A flag whose name contains a negative reads terribly when negated — if (!notFound) is a puzzle. Name the flag for the positive case and let ! do the work.

31. Comparing a boolean to true

Trap

if (evenFlag == true) {
    System.out.println("even");
}

if (evenFlag = true) {      // a single = : compiles in some languages
    System.out.println("even");
}

if (evenFlag) {
    System.out.println("even");
}

if (!evenFlag) {
    System.out.println("odd");
}

32. Well-named flag or not?

Definition probe

A flag's name should read as a claim that can be true or false.

33. Store and use a flag

Fill the middle

Set a flag from a comparison, then act on it.

34. When is a flag worth the extra line?

Socratic

You could always inline the comparison instead.

35. Boolean methods

Section

Section 5.8

36. A method can return true or false

Concept

Methods can return boolean values, just like any other type, which is often convenient for hiding tests inside methods. It is common to give such methods names that sound like yes/no questions.

public static boolean isSingleDigit(int x) {
    if (x > -10 && x < 10) {
        return true;
    } else {
        return false;
    }
}

Since the return type is boolean, the return statement has to provide a boolean expression. The name isSingleDigit sounds like a question, which is what makes the call sites read well.

37. The same method, written twice

Notation

The code above is straightforward, and longer than it needs to be. The expression in the condition is already a boolean.

This is the same observation as never compare a boolean to true, seen from the other side: a boolean expression is already the value you want, so wrapping it in machinery adds nothing.

38. Using a boolean method as a condition

Worked example

In main you can invoke the method in the usual ways — and conditional statements often invoke boolean methods and use the result directly as the condition.

System.out.println(isSingleDigit(2));      // true
boolean bigFlag = !isSingleDigit(17);      // true

if (isSingleDigit(z)) {
    System.out.println("z is small");
} else {
    System.out.println("z is big");
}

39. Simplify a boolean method

Fill the middle

Collapse the if-else into a single return.

40. Where you have already seen this

Concept

Boolean methods are not a new idea in the library. You are about to use one that has existed all along.

All four names are yes/no questions, and all four are used the same way — directly as a condition. The next section uses the first of them to make a program safe against bad input.

41. if (condition) return true; else return false;

Trap

public static boolean isPositive(int x) {
    if (x > 0) {
        return false;      // swapped by mistake
    } else {
        return true;
    }
}

public static boolean isPositive(int x) {
    return x > 0;
}

42. What does this display?

Prediction

A boolean method used three ways.

public static boolean isSingleDigit(int x) {
    return x > -10 && x < 10;
}
// in main:
System.out.println(isSingleDigit(2));
System.out.println(isSingleDigit(17));

43. Good name for a boolean method?

Discrimination

A boolean method's name should sound like a yes/no question.

44. Explain why the long form is worse

Explain it

The short form is not just shorter.

45. Validating input

Section

Sections 5.9-5.10

46. Never assume the user types what you expect

Concept

One of the most important tasks in any program is to validate input. People make mistakes while typing, especially on smartphones, and incorrect inputs may cause your program to fail. Worse, someone may intentionally try to break your system by entering unexpected input.

Scanner in = new Scanner(System.in);
System.out.print("Enter a number: ");
double x = in.nextDouble();
double y = Math.log(x);
System.out.println("The log is " + y);

Five lines of code, and two of the four inputs break it. You should never assume that users will input the right kind of data.

47. Two different checks, for two different failures

Notation

The two bad inputs fail in completely different ways, so they need completely different guards — and the order matters.

Two guards, in order: can it be read at all, and is the value usable. Nearly every input-validating program has that shape.

48. The complete program

Worked example

What started as five lines at the beginning of Section 5.9 is now a 30-line program. Making programs robust, and secure, often requires a lot of additional checking.

import java.util.Scanner;

/**
 * Demonstrates input validation using if statements.
 */
public class Logarithm {

    public static void main(String[] args) {
        // prompt for input
        Scanner in = new Scanner(System.in);
        System.out.print("Enter a number: ");

        // check the format
        if (!in.hasNextDouble()) {
            String word = in.next();
            System.err.println(word + " is not a number");
            return;
        }

        // check the range
        double x = in.nextDouble();
        if (x > 0) {
            double y = Math.log(x);
            System.out.println("The log is " + y);
        } else {
            System.out.println("The log is undefined");
        }
    }
}

It is important to write comments every few lines. They help other people read your code and help you document what you are trying to do — and if there is a mistake, good comments make it much easier to find.

49. What happens with input 'hello'?

Prediction

The validated version of the program.

if (!in.hasNextDouble()) {
    String word = in.next();
    System.err.println(word + " is not a number");
    return;
}
double x = in.nextDouble();

50. NaN, and why a bad value is worse than a crash

Concept

Math.log(-1) does not throw an exception. It returns NaN, which stands for not a number — and NaN propagates silently through every calculation it touches.

The second row is the more dangerous one, which is counter-intuitive. A crash tells you exactly where the problem is; NaN quietly contaminates everything downstream and only becomes visible at the very end, far from its cause.

51. Reading the input before checking it

Trap

double x = in.nextDouble();        // throws here if the input is "hello"
if (!in.hasNextDouble()) {
    System.err.println("not a number");
    return;
}

if (!in.hasNextDouble()) {
    String word = in.next();
    System.err.println(word + " is not a number");
    return;
}
double x = in.nextDouble();        // now guaranteed safe

52. Which check catches which failure?

Definition probe

Two guards, two distinct kinds of bad input.

53. Annotate the validated program

Error analysis

Five design decisions in thirty lines. Each was made for a reason.

Notice the asymmetry between the two checks. Bad format is unrecoverable and exits; bad range is a legitimate case with its own message. Deciding which of the two a failure is, is most of the design.

54. Where else do you validate before acting?

Real world

The has... then next... shape is a specific instance of a very general pattern.

55. The three logical operators

Comparison

Fill the blanks. The last column is the one people forget.

The last column is short-circuit evaluation, and it is the reason count != 0 && total / count > 10 is safe while the reverse order crashes.

56. The pattern to carry away

Pattern

Validating input is a guard clause followed by the normal path, and it is the shape most robust programs have.

// 1. guard: check the format, and leave if it is wrong
if (!in.hasNextDouble()) {
    System.err.println(in.next() + " is not a number");
    return;
}

// 2. now it is safe to read
double x = in.nextDouble();

// 3. check the range, and handle both cases
if (x > 0) {
    ...
} else {
    System.out.println("undefined");
}

• Short-circuit evaluation makes the left operand a guard for the right.
• De Morgan: negate each term and change the operator.
• Never compare a boolean to true or false.
• Return the condition, not true-or-false in two branches.

57. Check: short circuit

Check

Work it out before you click.

int[] nothing = null;
int n = 0;
if (n > 0 && 10 / n > 2) {
    System.out.println("yes");
}
System.out.println("done");

58. Check: De Morgan

Check

Work it out before you click.

59. Check: boolean methods

Check

Work it out before you click.

public static boolean isEven(int n) {
    return n % 2 == 0;
}
// in main:
if (isEven(7)) {
    System.out.println("even");
} else {
    System.out.println("odd");
}

60. Validation is a security question

Real world

Think Java raises this deliberately: someone may intentionally try to break into your system by entering unexpected inputs.

61. How sure are you?

Commit first

Commit to an answer and to your confidence.

62. Explain it to someone else

Explain it

Two minutes, out loud.

63. Exit ticket

Exit ticket

One question before you close the deck.

64. Draw the whole lesson

Connect it up

One page, from memory.

65. Recap

Recap

Six sections that turn conditions from single comparisons into real logic, and then use that logic to make a program safe.

• &&, || and ! combine boolean values; && needs both sides, || needs either, ! reverses one.
• Short-circuit evaluation skips the right operand when the answer is already decided — so the left operand can guard the right.
• ! binds tighter than >, so negating a comparison needs parentheses.
• De Morgan's laws: negate each term and change the operator. The opposite of < is >=, not >.
• A boolean variable is a flag, and you never compare one to true or false.
• A boolean method should be named like a question, and should return the condition rather than true-or-false in two branches.
• Validate the format before the range, because reading bad input throws before any range check can run.
• return exits a method early, and returning from main ends the program.