Brian Goetz brian.goetz at
Fri Jun 28 14:10:39 PDT 2013

> I have a different interpretation of close throwing an exception.  In
> many implementations of output streams and transactions everything
> happens in the close() - in the flush technically - so unless you're
> arguing for IOException unchecked, I think your reasoning has limited range.

The close action always has the option to throw an unchecked exception.

The code example shown earlier in Files.lines() does in fact convert the 
checked IOE into an UIOE.

> Closing a Reader, as opposed to Writer, is more likely innocuous but the
> programmer would still like to know about problems.  (I'm now wondering
> about the File.walk API: does it throw IOException?  Otherwise, how does
> an app know if the walk encountered an IO issue?)

Wraps IOE with UIOE.  It has to, since Spliterator.tryAdvance is not 
permitted to throw IOE.

> I'm worried that if this API extends to output Streams, we are opening
> ourselves up to silent errors.

Not silent.  Unchecked.

More information about the lambda-libs-spec-experts mailing list