RFR: JDK-8006884: (fs) Add Files.list, lines and find

[Henry Jen]

On May 3, 2013, at 1:39 PM, Henry Jen <henry.jen at oracle.com> wrote:

> I agree.
> 
> Now the question is that if we want to have this specified in CloseableStream or leave some wiggle room for implementations?
> 

Technically, there is no consistent way to detect if a Closeable is closed, thus no consistent way to implement it. We should leave it to implementation.

While I like ISE in this case, there were concerns about duality of IOException/UncheckedIOException, my guess it that same concerns would raise if we throw ISE. On the other hand, I wonder this should not be happening without calling close() method on the returned Stream explicitly, thus a distinguishable ISE make a lot of sense to me. Also consider close() as a terminal operation to the stream.

So, I will keep ISE as currently implemented, and probably add a statement to javadoc and a test case.

  * <p> When not using the try-with-resources construct, then the stream's
  * {@link CloseableStream#close close} method should be invoked after the
  * operation is completed so as to free any resources held for the open
  * directory. Operate the stream after it is closed will throw an IllegalStateException.

Cheers,
Henry

> Cheers,
> Henry
> 
> 
> On May 2, 2013, at 8:46 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
>> On 05/02/2013 08:22 AM, Alan Bateman wrote:
>>> On 02/05/2013 07:52, Henry Jen wrote:
>>>> Hi,
>>>> 
>>>> Please review a couple stream access API proposed for
>>>> java.nio.file.Files and java.nio.file.DirectoryStream,
>>>> 
>>>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/webrev/
>>>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.0/specdiff/
>>>> 
>>>> Cheers,
>>>> Henry
>>> One corner case that I meant to ask about is the expected behavior when
>>> someone attempts to do something on a CloseableStream after it is
>>> closed? It's not specified so it's not testable but I'm just wondering
>>> if the Iterator throwing ISE is right or whether this should be an
>>> UncheckedIOException. As I understand it, an ISE will be thrown if
>>> someone attempts to use a stream that already been operated on, so this
>>> really just leaves the uninteresting case where the stream is closed
>>> before using it.
>>> 
>>> -Alan.
>>> 
>> 
>> ISE sounds more interesting/helpful to the end user than a catch-all
>> UncheckedIOException, which just means "sh*t happened."
>> 
>> -- Jon
>> 
> 
>