CloseableStream exceptions [was: Re: experience trying out lambda-8-b74]

[Peter Levart]

On 02/04/2013 07:27 PM, Henry Jen wrote:
> On Feb 4, 2013, at 10:17 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> On 02/04/2013 06:55 PM, Henry Jen wrote:
>>> My preference is mainly build on top of that factory methods throws IOException. I still believe factory methods should throw IOException instead of wrap it up into UncheckedIOException so to enforce a try thus better reminds using try-with-resource to ensure close. So that is not going to change for those APIs in nio.
>> Why do you think throwing IOException would remind of using try-with-resource? The construct was designed for general AutoCloseable resources regardless of types of checked or unchecked exceptions thrown by creating, consuming or closing them…
>>
> Because of forcing a try block with checked exception. Better chance than unchecked exception. Also this is not defined by CloseableStream, it's the implementation class to decide what exceptions are proper.

I think that every new API or feature takes some time to get used. When 
try-with-resources was introduced, nobody was thinking to use it just 
because of java.io methods throwing checked IOException. I aggree that 
now many programmers mentally associate IOException with 
try-with-resources and you want to piggy-back on that mental perception. 
You might get quick response at the beginning, but for the price of 
long-term ugliness of exception handling when using the API. I expect 
people would be asking for another factory method throwing 
UncheckedIOException in JDK9 after the API is going to get used massively...

>>> The wrapping cost and suppress of exceptions(as in JDK 7[1]) is not really a big deal, it's great if we don't need them, but if we have to, we have to.
>>>
>>> On change the definition of CloseableStream, which would be preferred?
>>>
>>> CloseableStream<T> close();
>>>
>> you meant:
>>
>> void close();
>>
>> Could be, yes, but why not be more "documentary" and declaring it throwing the unchecked exception, like:
>>
>> void close() throws UncheckedIOException;
>>
> Because RuntimeException by convention won't be there, but in JavaDoc. In this case, we won't even mentioned in JavaDoc, the implementation class should decide if there are any RuntimeException it will need to throw and how.

Ah, sorry, I haven't noticed the package name of CloseableStream. I 
thought it was part of java.nio.file API, but it is in java.util.stream. 
Do you think a generic java.util.stream.CloseableStream is mandated? No 
API in java.util.stream uses it. Maybe it would be good just for 
enforcing the convention for any CloseableStream to not throw a checked 
exception on .close()...

In that case, yes, It should re-declare the close() by not throwing 
anything.

Regards, Peter

> Cheers,
> Henry
>