Level-up challenge · CSCD210

One program that reads two-line records with both kinds of Scanner read

You have finished the room on the leftover newline and you want one program where choosing the wrong kind of read is the difference between the right output and an empty one.

Unlocked at the end of: Arrays and file I/O, from zero, after the room the-leftover-newline. Room 12 closes the block of four rooms on how a Scanner reads. After it you can predict what every read in this program returns, which is the whole difficulty of the program.

Outcomes this shows4Inputs it is run on4Timeabout 45 minutesDifficulty2 of 3

What this shows you can do

Each line below is one outcome, written the way the course records it. A program that does the whole task shows all of them at once.

Student can choose between Scanner token methods (next, nextInt, nextDouble) and line methods (nextLine) based on the file format, and predict what each call consumes from the buffer.
In this program: Every field in this format needs a decision about which kind of read to use. Measured: reading the description with a token read ends the run with InputMismatchException on the next quantity, and reading the part name with a line read puts a second space into every item line.
Student can predict what sc.nextLine() returns given the file's current cursor position, identify that the line terminator is consumed but not part of the return value, and recognize the three cases: non-empty line, empty line, partial last line: by what each returns.
In this program: Each description is printed inside round brackets on a line of its own, so a terminator that came back with the description would break every item line. Measured: a version that assumes the terminator arrived and prints without a line break of its own runs the whole list together on one line. Check c4 ends without a final newline, so the last description is the partial last line.
Not shown by a run:The empty-line case as a genuinely empty line in the input. The empty return is exercised, because the discarding read returns it once per item, and an empty description is left out of every check on purpose. An empty description and a description lost to the leftover newline print the same three characters, and a check that cannot tell those two apart is not a check.
Student can choose between next(), nextInt(), nextDouble() for reading from a Scanner based on the expected token type, predict the exception thrown when the token cannot be parsed (InputMismatchException), and recognize the cursor-position rule that produces the trailing-whitespace trap.
In this program: The quantity has to arrive as a number and the part name as a word, and the total line is what makes the number real. Measured: a version that assumes nextInt consumes the whole record line puts a second space in front of every part name, and a version that reads the description with next() ends the run with InputMismatchException.
Not shown by a run:nextDouble, and the clause about predicting the exception. No value in this format is a decimal, because nextDouble reads the decimal mark from the runner's locale and a check that depends on the runner's locale fails for a reason a student cannot see. A correct run never meets a token that fails to parse either, so nothing a correct program prints names InputMismatchException. Two of the probes below end with it, which is the consequence of a wrong read rather than a student predicting the exception.
Student can predict that a nextLine call immediately after a nextInt (or any token-mode read) returns the empty string, and apply one of the two standard fixes (discard newline with an extra nextLine, or stay in token mode).
In this program: This is the whole program. Measured: leaving out the discarding read ends the run with InputMismatchException on any list of more than one item, and prints an empty description on a list of exactly one, so no check passes either way.

What to build

Write one program named SupplyList.

It reads a supply list from standard input.

The first line holds a whole number, which is how many items the list holds. There is at least one item.

Each item takes two lines. The first of the two holds the quantity, a space, and the part name, where the quantity is a whole number and the part name is a single word. The second of the two is the description, which is free text and may hold spaces and commas. Every description holds at least one character. The last line of the input may or may not end with a line break.

The program prints the list back.

The first line is the label items, a colon, one space, and how many items the list holds. After that comes one line per item, in the order the items arrived. An item line is the quantity, a space, a lowercase x, a space, the part name, a space, and then the description inside round brackets. The last line is the label total units, a colon, one space, and the sum of every quantity.

Print nothing else, and print no prompt.

The rest of the program is yours to shape.

One worked example

The first of the inputs, with what the program prints for it.

Three items with ordinary descriptions, every description holding a space and a comma

This is the shape a token read cannot deliver, so it separates a line read from a token read on the description.

Input

3
4 bolts
hex head, half inch
12 washers
flat, quarter inch
2 clamps
spring clamp

Output

items: 3
4 x bolts (hex head, half inch)
12 x washers (flat, quarter inch)
2 x clamps (spring clamp)
total units: 18

How your program is checked

Your program is run once for each input and its output is compared with what is shown. The worked example above is the first of them. You can run every one of them yourself before you hand anything in.

One item, the smallest list the spec allows

A missing discarding read does not end the run here the way it does on a longer list, and the empty description it prints instead is what this check catches.

Input

1
7 dowels
oak, six inch

Output

items: 1
7 x dowels (oak, six inch)
total units: 7

Five items, including a one-word description and a three-digit quantity

The one-word description is the case a token read on the description would get right, so a program that passes only on that item fails here on the rest.

Input

5
20 screws
phillips
3 hinges
brass, three inch
100 nails
common, two inch
1 level
twenty four inch
9 anchors
plastic

Output

items: 5
20 x screws (phillips)
3 x hinges (brass, three inch)
100 x nails (common, two inch)
1 x level (twenty four inch)
9 x anchors (plastic)
total units: 133

Two items, and the input ends without a line break after the last description

This is the partial last line, the third case the line-read observable names, and a program that only works on input ending in a line break fails here.

Input

2
6 shims
plastic, thin
15 nuts
zinc, quarter inch

Output

items: 2
6 x shims (plastic, thin)
15 x nuts (zinc, quarter inch)
total units: 21

What to watch for

Each one is copied from the notes for the rooms this challenge draws on, with what a run shows when it happens.

blaming nextLine for "returning nothing"
What a run shows: On c1, c3 and c4 the run ends with InputMismatchException before anything prints, because with no discarding read the next quantity read lands on a description. On c2 the run finishes and prints one item with an empty description and the right total, which is the same list with nothing in the brackets.
adding sc.nextLine() flushes in the wrong place
What a run shows: Every item line prints with empty brackets and every quantity and the total are right, so the run looks healthy and every check fails on the same missing text.
trying to fix the trap with sc.skip(...)
What a run shows: Nothing, on this platform. Measured: skip("\n") in place of the discarding read produced output identical to the reference on all four checks, because the input holds LF line breaks and the pattern matches one exactly. The leaf objects to the idiom for being fragile across platforms rather than for failing here, and the checks agree with the leaf.
assuming nextInt() reads a whole line
What a run shows: Every item line carries a second space in front of the part name, because a line read after the quantity returns the rest of that line with its leading space still on it. Every quantity, description and total is right, so the only wrong thing on the page is a space.
mixing next() and nextInt() and expecting them to behave like nextLine()
What a run shows: The run ends with InputMismatchException before anything prints, because a token read takes only the first word of the description and the next quantity read lands on the second word.
assuming an empty String return means EOF
What a run shows: The list stops after the first item. Every later item line prints a zero quantity and the word null twice, and the total is the first quantity alone.
expecting nextLine() to include the \n
What a run shows: Every item and the total run together on one line, because a program written on that assumption leaves out the line break of its own that the output needs.
mixing hasNextInt with nextLine reads
What a run shows: Nothing, with these four inputs. Measured: replacing the counted loop with a hasNextInt guard produced output identical to the reference on all four checks, because no description line in any of them begins with a number. A fifth input whose description began with a number would separate the two, and writing one would make the guard the subject of the challenge rather than the reads.

What this puts on your resume

You have written Java that reads a record spread across two lines of input, choosing a token read or a line read for each field and handling the newline that a token read leaves behind.

What the program needs where it runs

The sandbox has to supply the check input on standard input.
This program creates no file and reads none, so it needs no writable folder and no folder of its own per check.
Not yet confirmed on the deployed runner. This was verified locally only. No call was made to the Judge0 host from this pass.

Notes for the author, not part of the student page

This block is here so the manifest can be reviewed on the page instead of in the file. It is not rendered on a student page.

Outcomes considered and left out

scanner-over-file-construct-and-close. This program reads standard input rather than a file. A check supplies standard input and nothing else, and the room that writes a file comes later in the path, so a challenge unlocked here has no way to put a file on disk for the program to open. The buffer rules the four certified leaves are about do not change with where the bytes came from, and the file-io-capstone challenge already certifies this leaf on a real file.
line-mode-end-of-file-loop. The count arrives on the first line, so the program walks a counted loop and never asks whether more input is left. The path does not reach the end-of-file loop until the file-into-an-array room, which comes after this challenge unlocks.
file-not-found-exception-is-checked. No file is opened, so no constructor throws it and no method header needs the declaration.
checked-versus-unchecked-classification. Nothing here is caught or declared, so no run of this program shows the rule.

Why a run cannot see some clauses

typed-token-reads-and-inputmismatch. The locale reason is the fourth pitfall on this leaf, which the leaf itself names. The exception reason is that naming an exception in output needs a catch block, and the catch-syntax concept is not on this path.

Scope decisions

nextline-after-token-read-trap. The observable names two standard fixes and this format allows only the first. A description holds spaces, so staying in token mode cannot read it. That is deliberate. The discarding read is the fix a student has to be able to write, and a format that let either fix through would let a student pass without ever meeting the leftover newline.

Carried in from earlier rooms

counted-for-loop-over-array, from the room walking-every-slot, at working depth
accumulator-sum-and-average-cast, from the room computing-while-you-walk, at working depth

Assumed from earlier in the course

Reading from standard input with a Scanner. Not a leaf in this seed unit, which covers arrays and file I/O only. The practice bank has it earlier in the course at lane-04-loops/07-accumulator-pattern/01-running-sum/exercises/sum-range-with-scanner.yaml, which reads an integer from standard input with a Scanner.

Where the expected output came from

solution: _reference/scanner-reading-modes/SupplyList.java
inputs: _reference/scanner-reading-modes/cases/
compiler: javac 25.0.1 (Temurin 25.0.1+8-LTS)
runtime: openjdk 25.0.1 2025-10-21 LTS (Temurin 25.0.1+8-LTS)
platform: macOS 26.5.2, arm64
captured: 2026-08-21 3:52 PM PDT, clock read with date
command: javac -d . SupplyList.java, then java -cp . SupplyList < cases/<id>.stdin with the output redirected to cases/<id>.stdout. This program creates no file, so the cases do not need a folder of their own the way the file-io capstone cases do.
normalization: Java writes LF on this platform, so nothing was converted. Every captured file was counted for CR bytes and every count was zero.
run limits: 5 seconds of processor time and 131072 kilobytes, which are the practice bank values

Provenance

authored: 2026-08-21 between 3:40 and 4:10 PM PDT, clock read with date
spine_read: Leaf observables and pitfall headings read 2026-08-21 afternoon from ~/Projects/jdoner-me-universe/spine/cscd210/07-file-io-and-exceptions/, and every quote in this file was extracted from checks.yaml and pitfalls.md by script rather than typed.
path_read: Room membership read the same afternoon from ~/Projects/jdoner-me-universe/paths-prototype/paths/cscd210-arrays-fileio-catchup.yaml, into which the same unit added the four rooms this challenge unlocks after.
agent: CC-MAC-JDONERME-0821, Sprint 2, unit u05.

What this shows you can do

What to build

One worked example

Three items with ordinary descriptions, every description holding a space and a comma

How your program is checked

One item, the smallest list the spec allows

Five items, including a one-word description and a three-digit quantity

Two items, and the input ends without a line break after the last description

What to watch for

What this puts on your resume

What the program needs where it runs

Mark it built

Notes for the author, not part of the student page

Outcomes considered and left out

Why a run cannot see some clauses

Scope decisions

Carried in from earlier rooms

Assumed from earlier in the course

Where the expected output came from

Provenance