experience trying out lambda-8-b74

[Henry Jen]

On 01/28/2013 12:16 AM, Peter Levart wrote:
> On 01/28/2013 12:06 AM, Henry Jen wrote:
>>
>> http://cr.openjdk.java.net/~henryjen/lambda/nio.5/webrev/
>>
> Hi Henry,
> 
> I can imagine that many times a single block of code would be
> responsible for constructing a Path stream (possibly enclosed into a
> try-with-resources construct) and consuming it's results, so having to
> deal with the duality of IOException/UncheckedIOException is a
> complication for a user in my opinion. Wouldn't it be better also for
> the stream-factory methods to throw UncheckedIOException and for
> CloseableStream.close() to also throw UncheckedIOException (that means,
> only inheriting from AutoCloseable, not Closeable and co-variant-ly
> redefining the throws declaration):
> 
> public interface CloseableStream<T> extends Stream<T>, AutoCloseable {
>     @Override
>     void close() throws UncheckedIOException;
> }
> 

Hi Peter,

Sorry for the late reply, I want to let the idea sink a little bit.

After couple days, I am slightly prefer not to change it because,

1) The CloseableStream-factory method throws IOException reminds use of
try-with-resource better than an unchecked exception.

2) As factory methods throwing IOException, developer is dealing with
duality already.

3) If the close method throws UncheckedIOException as the stream
handling, the suppressing of exceptions will be more confusing. Should
developer look into cause IOException or the UncheckedIOException?

4) When the implementation is a Closeable, the wrapping of IOException
into an UncheckedIOException doesn't do any good except overhead in case
developer want to deal with it. On the other hand, a IOException handler
is probably in place as the factory methods throws IOException.

Does it make sense?

I updated the webrev to have some test coverage for exception handling,
it's painful as always, but the duality is not what bothers me.

http://cr.openjdk.java.net/~henryjen/lambda/nio.6/webrev/

Cheers,
Henry