UncheckedIOException and suppressed exception

[Zhong Yu]

On Sat, Feb 9, 2013 at 9:47 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 02/08/2013 03:38 PM, Zhong Yu wrote:
>
> 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.
>
>
> Hi Zhong,
>
> That's true. And that would be dangerous for AutoCloseable resources that
> "buffer" output and "flush" it when closed. But Stream<Path> or any
> potential CloseableStream seems to be an inherently "input" resource. Is it

One could open a FileChannel for read/write, first write something to
it, then wrap it as a CloseableStream<String>, relying on
CloseableStream.close() to trigger FileChannel.close() to persist the
file. So a read-only stream isn't necessarily based on a read-only
resource.

Zhong Yu


> really possible that closing an open directory fails on any OS? I think that
> CloseableStream could thrown an IOError in that case, indicating that there
> is really something wrong with the platform logic or the state of OS. The
> linux closedir specifies the following for example:
>
> RETURN VALUE
>        The closedir() function returns 0 on success.  On error, -1 is
> returned, and errno is set appropriately.
>
> ERRORS
>        EBADF  Invalid directory stream descriptor dirp.
>
> ...such error should really not occur...
>
>
> 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()?
>
>
> Might be just to filter the files using lambdas? But I agree that most of
> the times the processing of Paths would be done inside the Streams API too.
> I would do it that way...
>
> If all IOExceptions were consistently wrapped with UncheckedIOExceptions
> then when one wanted to deal with several IOException subtypes, (s)he would
> have to do the unwrapping in the handler at the end of try-with-resources,
> like for example the following:
>
>
>         try (CloseableStream<Path> = ...) {
>                 ... Stream<Path> operations throwing UncheckedIOException
>         }
>         catch (UncheckedIOException uioe) {
>             try {
>                 throw uioe.getCause();
>             }
>             catch (EOFException eofe) {
>
>                 // ...
>             }
>             catch (ZipException ze) {
>                 // ...
>             }
>             catch (IOException ioe) {
>                 //...
>             }
>         }
>
> Not bad but not any better either. Only when it doesn't matter which kind of
> IOException is thrown, the consistent wrapping with UncheckedIOException
> simplifies things. I think it would be necessary to try to write some
> real-world examples, like you proposed, to establish the right attitude.
>
> Regards, Peter
>
> Zhong Yu
>
>