CloseableStream exceptions [was: Re: experience trying out lambda-8-b74]
peter.levart at gmail.com
Mon Feb 4 11:02:47 PST 2013
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) 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
More information about the lambda-dev