UncheckedIOException and suppressed exception

Zhong Yu zhong.j.yu at gmail.com
Fri Feb 8 06:38:05 PST 2013


On Tue, Feb 5, 2013 at 3:47 AM, Peter Levart <peter.levart at gmail.com> wrote:

>         try (CloseableStream<Path> = ...) {
>             try {
>                 ... direct Path operations throwing IOException and/or
>                 ... Stream<Path> operations throwing UncheckedIOException
>             }
>             catch (UncheckedIOException uioe) { throw uioe.getCause(); }
>         }
>         catch (EOFException eofe) {
>             // ...
>         }
>         catch (ZipException ze) {
>             // ...
>         }
>         catch (IOException ioe) {
>             //...
>         }


There's a bug - the exception from CloseableStream escapes handling
and creeps away.

Since closing is hidden in a try-with-resource statement, people often
forget about it, therefore close() should throw the same type of
exception as opening. If CloseableStream.close() throws IOException,
the bug won't exist.

I'm still at the position that opening/closing the stream should throw
UncheckedIOException, so that the entire try-with-resource statement
throws a consistent exception type.

    try(stream = openStream())
        using stream
    catch(UncheckedIOException e)
        handle e

I'm not convinced that "using stream" could involve IOException; why
would one call Files.list() to get a Stream<Path>, then turn it into
Iterator<Path> to operate on files "in the open", why he could simply
use the good old Files.newDirectoryStream()?


Zhong Yu


More information about the lambda-dev mailing list