Re: Exception in finally block

Chris Smith <cdsmith@twu.net> wrote or quoted in
Message-ID: <MPG.1fdc23c27eb9a34989776@news.altopia.net>:


My previous article has a connection with Tom Hawtin's article.
I do not want to deduce your comment on his example from
your comment on my previous article. What is your comment
on Tom Hawtin's example ?

There is my additional view of Tom Hawtin's example. First,
the following code is a part of "BufferedWriter" source.

<code>
public void close() throws IOException {
    synchronized (lock) {
        if (out == null)
            return;
        flushBuffer();
        out.close();
        out = null; // #1.
        cb = null; //
    }
}
</code>

I think that the author of "BufferedWriter" has intention to
assign null to "out" and "cb" when "close()" is called.

But, the following code discards the intention because
"out.close()" is not called.

<code>
//
// quoted from Tom Hawtin's article.
//
try {
     Writer rawOut = ...l;
     try {
         BufferedWriter out = new BufferedWriter(rawOut);
         ...
         out.flush();
     } finally {
         rawOut.close();
     }
} catch (IOException exc) {
     ...
}
<code>


I think that IOException of steam should not make a mess in
consistency of performance. Lets consider the following code.

<code_2>
//
// quoted and modified from my previous article.
//
void processXX(T1 o1, T2 o2) throws XXException, IOException {

    ... stream = ...;
    try {
         { code block #1} // The state of o1, o2 are changed;
         { code block #2} // data are IOed to/from stream.
         ....
    }
    finally {
        stream.close();
    }
}

//
// Main routine..
//
try {
    ...
    processXX(o1, o2);
    ...
}
catch (XXException e) {
    // restore o1, o2.
}
catch (IOException e) {
   // ..
}
</code_2>

The method "processXX" do not guarantee the consistency
of performance.

After { code block #1}, if XXException occurs and successively
IOException of "stream.close()" occurs, the state of o1, o2 can
not be restored to the previous state. Because the XXException
was discarded by the IOException. ( Consider more than one
XXExceptions.)

Closing the stream will be not failing for a different reason than
the original I/O operation. But, IOException of stream.close()
can swallow up other exceptions (XXExceptions).

I think, the failure of "stream.close()" makes no matter in practice.
It is important that other exceptions can be swallowed up.

Do you think that the following code implies that a developer scatter
code to report unexpected exceptions all over his code base ?

<code>
try {
    ...
}
catch (...) {
    ...
}
finally {
    try {
        stream.close();
    }
    catch (Exception e) {
       ...
    }
}
</code>