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

Peter Levart peter.levart at
Mon Feb 4 12:35:22 PST 2013

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 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

More information about the lambda-dev mailing list