Validation & Parsing

Input text is not automatically a usable number. Integer.parseInt converts a String containing a valid whole-number representation to an int. Integer is a Java library class available without an import; parseInt is its static method, so you call it on the class name rather than on a new object. trim can remove surrounding spaces first. Numeric syntax (how a number is written) and domain rules (what your application allows) are separate: “0” can parse successfully while zero is still invalid for a session duration.

A contract should say what is accepted. Our final planner accepts a nonblank topic, trimmed at its edges, and a duration from 1 through 240 inclusive. Types alone cannot enforce these rules. Validate before storing a record, so rejected input cannot leave a half-created plan behind.

Guard references before calling methods

A String reference can be null, meaning no object. Test null before calling trim or isEmpty on it. The short-circuit operator from Day 2 makes this readable: null is rejected first, and the text operation is evaluated only when an object exists. Empty text and a string of spaces are different before trimming, but both fail our nonblank-topic rule afterward.

Some parsing inputs fail with NumberFormatException: letters, decimals where a whole number is required, or numbers outside int’s range. The next lesson handles that failure explicitly. For now, run known-valid parsing examples and keep the boolean domain checks independently testable.

public class Main {
    public static void main(String[] args) {
        String text = " 25 ";
        int minutes = Integer.parseInt(text.trim());

        System.out.println(minutes);
        System.out.println(validMinutes(minutes));
        System.out.println(validMinutes(0));
    }

    static boolean validMinutes(int minutes) {
        return minutes >= 1 && minutes <= 240;
    }
}

25
true
false

Parsing gives an integer, not permission to schedule it. Check 1, 240 and 241 as independent domain cases. The parsing step does not know anything about sessions or a daily plan.

public class Main {
    public static void main(String[] args) {
        System.out.println(validTopic(null));
        System.out.println(validTopic("   "));
        System.out.println(validTopic(" Java "));
    }

    static boolean validTopic(String topic) {
        return topic != null && !topic.trim().isEmpty();
    }
}

false
false
true

If topic is null, && skips the trim call. Reversing those operands would break the null case. Validation accepts a nonblank value but does not mutate the original String.

public class Main {
    public static void main(String[] args) {
        Tally tally = new Tally();
        System.out.println(tally.add(25));
        System.out.println(tally.add(-5));
        System.out.println(tally.total());
    }
}

class Tally {
    private int total;

    boolean add(int minutes) {
        if (minutes < 1 || minutes > 240) {
            return false;
        }

        total += minutes;
        return true;
    }

    int total() {
        return total;
    }
}

true
false
25

A failed update returns false and leaves the previous total intact. Test both the reported failure and the state afterward. Moving the mutation before validation violates this contract.

Your turn

public class Main {
    public static void main(String[] args) {
        System.out.println(validMinutes(0));
        System.out.println(validMinutes(25));
    }

    static boolean validMinutes(int minutes) {
        return false; // Replace the placeholder.
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(validMinutes(0));
        System.out.println(validMinutes(25));
    }

    static boolean validMinutes(int minutes) {
        return minutes >= 1 && minutes <= 240;
    }
}

false
true

Change it and explain

Write a small acceptance table containing raw text, parsed value if any, domain validity and expected action. Include “25”, “0”, “241”, “oops” and an empty string. This makes the distinction between parse failures and rule failures visible before you introduce recovery code.

Validation is not a reason to catch every possible exception and pretend input was accepted. A clearly rejected record is more useful than a silent zero that later looks like real data. In the final project, successful records are added only after construction has validated them.