System in can use less home-made code #16
Conversation
ashleyfrieze
commented
Nov 13, 2020
ashleyfrieze
commented
- Surprising behaviour with Scanner suggests home-made code acted unusually
- Surprising behaviour with Scanner suggests home-made code acted unusually
| .execute(() -> { | ||
| Scanner scanner = new Scanner(System.in); | ||
| scanner.nextLine(); | ||
| assertEquals("first line", scanner.nextLine()); |
There was a problem hiding this comment.
Increase clarity of the second assert
| ).execute(() -> { | ||
| Scanner firstScanner = new Scanner(in); | ||
| firstScanner.nextLine(); | ||
| Scanner secondScanner = new Scanner(in); |
There was a problem hiding this comment.
The first scanner may cache more than just the first line, so the second scanner is unable to pick up the second line.
| .execute(() -> { | ||
| int numBytesRead = System.in.read(DUMMY_ARRAY, VALID_OFFSET, 0); | ||
| assertThat(numBytesRead).isZero(); | ||
| assertThat(numBytesRead).isEqualTo(-1); |
There was a problem hiding this comment.
read should return -1 at the end of the stream.
- Surprising behaviour with Scanner suggests home-made code acted unusually - Interface for `read` was broken - should return `-1` at stream end
|
I've encountered some surprises with this implementation. I think the home made stream was there to solve a problem that was not covered by the original unit tests for SystemLambda. I've put the missing tests into #18 I'd like a little clarification, please. What's the intended behaviour? Some of the tests in #18 will likely fail if we use more conventional implementations of |
|
Further review suggests that this is not a viable solution... worth exploring whether the behaviour in #18 is what's expected. |
1 participant
