التحقق من المدخلات: لا تثق بالمستخدم أبداً

Written Explanation

Why input cannot be trusted

Input is anything that comes from outside the code you wrote: the keyboard, a file, a web request, a command-line argument. You do not control it, so assume it can be:

The OWASP Input Validation Cheat Sheet, a widely used guide for developers, makes two points we use here. First, validation covers both the form of a value and whether it makes sense for the operation, and its own example is a booking whose end date must come after its start date. Second, it recommends defining what is acceptable and rejecting everything else (an allowlist), instead of trying to list every bad value.

For our small programs the allowlist is simple: a whole number from 1 to 10 means exactly that and nothing else.

Two kinds of check

1. Format: can the text be read as the type I need? hasNextInt() answers that for an int.
2. Range or meaning: is the value sensible? A quantity must be at least 1; an age is probably below 150; a price must be above zero.

A value can pass the first check and fail the second: -5 is a perfectly good int. Both checks are needed.

The decision: if

You saw the shape in Lesson 3. A condition inside parentheses is either true or false, and the block runs only if it is true:

if (qty >= 1) {
    // runs only when qty is 1 or more
}

The conditions use the comparison and logical operators of BEG-010: >=, <=, && ("and"), ! ("not").

The repetition: while (true) and break

A while loop repeats its block as long as its condition is true. while (true) never stops by itself, so we use break to leave it from the inside once the input is good:

while (true) {
    // ask, read, check
    // if the answer is good: break;
}

Read it as "keep doing this forever, until a break is reached". It is a very common pattern for input, and BEG-013 explains loops and break in more detail.

The complete pattern

int qty;
while (true) {
    System.out.print("Quantity (1-10): ");
    if (in.hasNextInt()) {
        qty = in.nextInt();
        if (qty >= 1 && qty <= 10) {
            break;                  // good answer: leave the loop
        }
    } else {
        in.next();                  // discard the bad token
    }
    System.out.println("Enter a whole number from 1 to 10.");
}

Walk through it:

1. Print the prompt.
2. hasNextInt() asks "is a whole number waiting?" without reading it. If yes, read it with nextInt().
3. Check the range. If it passes, break leaves the loop. If not, the code falls out of the if and reaches the error message, and the loop starts again.
4. If no whole number is waiting, discard the bad token with in.next(), print the message, and loop again.

When the loop ends, qty is guaranteed to hold a whole number from 1 to 10. Everything after the loop can rely on that.

Why in.next() matters

hasNextInt() only looks. If it returns false, the bad token is still waiting. Without the discard, the loop asks hasNextInt() again, the same bad token is still first in line, the answer is false again, and the program prints the error message forever without waiting for the user. This is an infinite loop. A deliberately broken version, limited to three tries so it is safe to run:

int count = 0;
while (!in.hasNextInt() && count < 3) {
    System.out.println("Try again");
    count++;
}

With abc typed, the real output is:

Try again
Try again
Try again
stopped after 3

It never waited for new input, because abc was never removed. in.next() removes exactly one token: the bad one. (If the user typed several words, the loop handles them one at a time and prints the message once per bad token. That is acceptable for a first version.)

Validation with lines: text and decimals

For text fields, the check is often "not empty". The String method trim() removes spaces at both ends, and isEmpty() is true for text of length zero. (BEG-009 gave length(); isEmpty() is the same check as length() == 0.) A name made of spaces only is also empty:

String name = in.nextLine().trim();
if (name.isEmpty()) {
    // ask again
}

For a decimal such as a price, a tidy way to check a line is to hand the text to a small temporary scanner and ask hasNextDouble(). Here is a complete, tested loop. It uses continue, which means "skip the rest of this round and start the next round":

double price;
while (true) {
    System.out.print("Price: ");
    String line = in.nextLine().trim();
    if (line.isEmpty()) {
        System.out.println("Type a price.");
        continue;
    }
    if (!new Scanner(line).hasNextDouble()) {
        System.out.println("Not a number.");
        continue;
    }
    price = Double.parseDouble(line);
    if (price > 0) {
        break;
    }
    System.out.println("Price must be above zero.");
}

The ! means "not". new Scanner(line) makes a throw-away scanner that reads from a String instead of the keyboard. It uses the locale rules of Lesson 1, so on a comma-decimal machine test with the formats you intend to accept.

The sneaky decimals: NaN and Infinity

Decimal parsing accepts the words NaN ("not a number") and Infinity. In a compiled test, Scanner reported hasNextDouble() as true for both. Look at what comparisons do with them:

• NaN > 0 is false, and NaN < 0 is also false. So the check price > 0 rejects NaN, but a check written as "reject if price < 0" would let it through.
• Infinity > 0 is true. A check for "above zero" alone accepts it.

This is a good reason to write the check as "accept only if it is in the range I want", the allowlist way, and to set an upper bound where there is a sensible one. A realistic price check would be price > 0 && price < 100000 or whatever your business allows.

Good error messages

A message such as Invalid input tells the user nothing. A good message says what is expected: Enter a whole number from 1 to 10.

Validation never ends at the keyboard

The same rules apply to every program that takes input from anywhere. For a web service, validation in the browser is only a convenience: OWASP's cheat sheet says client-side checks can be bypassed, so the server must validate again. Injection attacks, in which a stranger's input is treated as part of a command, depend on a program that trusted its input.