ppkarwasz commented on PR #790:
URL: https://github.com/apache/commons-io/pull/790#issuecomment-3346011387
Hi @garydgregory,
I’ve fixed the failing tests in commit
051a86a3c28eece62e8008c31435e274d7ef342e. The failures stemmed from a few
subtly incorrect assumptions in the original tests or my code. Below is a
breakdown of what I changed and why:
1. **Empty buffer read after EOF**
Some tests expected `read(buf, off, 0)` to return `-1`. However, the
[Javadoc for `InputStream.read(byte[], int,
int)`](https://docs.oracle.com/en/java/javase/25/docs/api//java.base/java/io/InputStream.html#read(byte%5B%5D,int,int))
explicitly states that if `len == 0`, it should return `0` without attempting
to read. I updated the tests to reflect that behavior.
2. **Null + out-of-range ambiguity**
Several tests assumed a particular exception type when both the array is
`null` and indexes are invalid. I refactored the tests so each invalid case is
tested separately, making them less brittle and clearer.
3. **Closed streams and order of checks**
Some `Reader`/`Writer` tests expect an `IOException` when the stream is
closed, even if the call’s arguments are invalid. While the Javadoc doesn’t
mandate the order, this matches the de-facto behavior of most core `java.io`
readers/writers: they check the closed state first and only validate arguments
if the stream is open. I updated the implementations under test to follow this
convention.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
