Input Arrives as Data You Still Have to Interpret

A user typing 42 sees a number. A line-oriented input system first gives your program text.

Concept flow

Input becomes trustworthy only after interpretation

Receiving text, parsing a Java type, and validating a domain rule are separate boundaries.

1. RAW TEXTreceive characters from an input boundary
   parse
2. PARSEattempt conversion into a Java type
   produce
3. TYPED VALUEhold the converted representation
   validate
4. DOMAIN RULEdecide whether the typed value is acceptable
   use
5. APPLICATION STATEonly validated meaning drives later behavior

Java 25's IO.readln makes that visible without forcing us into a larger input API immediately.

void main() {
    String text = IO.readln("Enter a test count: ");
    IO.println("You entered: " + text);
}

At this point text is a String. The characters might be 42, forty-two, an empty line, or something else.

Parsing is a claim

If the program needs an integer, it can attempt to parse:

int count = Integer.parseInt(text);

That line makes a claim:

text contains a valid representation of an int

If the claim is false, the program can compile perfectly and then fail during execution with a NumberFormatException.

That distinction matters. The syntax is valid. The type relationship is valid. The runtime data violates an expectation.

A small interactive program

Run:

void main() {
    String name = IO.readln("Name: ");
    String countText = IO.readln("Completed tasks: ");
    int count = Integer.parseInt(countText);

    IO.println(name + " completed " + count + " tasks.");
}

Test at least these inputs:

Notice the difference between parseable and acceptable.

-2 can be parsed into an integer. But a negative count of completed tasks may violate the application's rules.

Parsing answers:

Can these characters become this Java type?

Validation answers:

Is this typed value allowed in this application?

Those are separate boundaries.

Do not hide invalid data yet

Later you will handle invalid input gracefully. For now, preserve the failure. Read the exception enough to identify:

• the exception type;
• the data that triggered it;
• the line responsible for interpreting the data.

Do not paste the entire stack trace into your evidence and call that analysis.

Build an input contract

For a fictional competition scoring tool, define inputs for:

• team name;
• match number;
• points scored;
• whether a penalty occurred.

For each input, write:

raw form received:
target Java type:
parse rule:
domain validation rule:
example valid value:
example parse failure:
example parseable but invalid value:

You have just designed an input boundary before writing the complete application.

That habit scales. Most real systems fail less often when assumptions about incoming data are visible instead of scattered through the code.