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

[Peter Levart]

On 02/04/2013 08:45 PM, Alan Bateman wrote:
> On 04/02/2013 19:02, Peter Levart wrote:
>>
>> 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...
>>
> All methods to open or access files, directories, etc. in this API 
> throw the checked IOException. It would be inconsistent to introduce a 
> parallel set of methods at this point, particularly because this API 
> also defines also many specific IOExceptions for cases where recovery 
> might be required for specific cases.

Are the specific IOExceptions only relevant when creating the stream or 
also when consuming and/or closing it?

>
> So I think if CloseableStream is used in a try-with-resources that 
> opens the file or directory then it will probably lead to usages such as:
>
> try (...) {
>      :
> } catch (UncheckedIOException e) {
>     throw e.getCause();
> }

The above example would stay exactly the same if the factory method 
threw UncheckedIOException.

>
> or
>
> try (...) {
>     :
> } catch (IOException ioe) {
>     throw new UncheckedIOException(ioe);
> }
>

The catch and manual wrap in UncheckedIOException in above example would 
not be needed if the factory method threw UncheckedIOException already...

> depending on whether you want to propagate a checked or unchecked 
> exception. One of two examples in the javadoc might help.
>
> -Alan.
>

Regards, Peter