Re: finally block does not complete normally - Eclipse

cdsmith@xxxxxxx wrote in comp.lang.java.programmer:
> Antti S. Brax <asb@xxxxxxxxxxxxxx> wrote:
>> Please don't forget to put a try-catch block inside the finally
>> block (this is very important in example code because people use
>> it to learn things).
>
> I strongly disagree that it's a good idea to put a try/catch inside the
> finally.
>
> After all, what do you intend to do with the exception when you catch
> it? Are you saying that the code that reads the file ought to have
> knowledge of the exception handling strategy for the software?

Hell yeah! It would be silly to demand that a software does not
know it's own exception handling strategy.

<snip>
> Too often, people taking this kind of advice -- to always handle
> exceptions -- do something ineffective, like just write it to standard
> output then drop it.

You are generalizing a very specific issue here (but I agree
with your generic advice anyway).

> The problem is that if finally executes because
> the original code completed normally, then you miss proper handling of
> the exception and it very likely gets forgotten. That leads to
> undetected faults in cases like running out of disk space while flushing
> the buffers at the end of a write operation.

I see that you have a point and I agree partly. But how exactly
should the exception handling be done in the finally block so
that no important information is hidden from the caller? I came
up with a solution, but it is quite ugly and not at all perfect
(exception thrown in finally is still "hidden" if an exception
is thrown in try).

fos = new FileOutputStream(FILENAME);
boolean errors = true;
try {
// Manipulate output stream.
} finally {
try {
fos.close();
} catch (IOException ex) {
if (errors) {
// Log exception.
} else {
// Rethrow the exception.
}
}
}

Since it is likely (as you also say below) that whatever is
thrown in the close might be caused by the same error that
caused the earlier exception, it is more important to pass
the earlier exception to the caller.

> Generally speaking,
> though, the two exceptions will be caused by EXACTLY the same thing, and
> having just one of the two exceptions for debugging is good enough.

No. The earlier exception is much more important, since it
also contains information about the state in which the (please
forgive me) "business logic" was when things went wrong. This
is usually quite important especially if fixing the problem
involves cleaning up things that were left in an invalid state.

--
Antti S. Brax Rullalautailu pitää lapset poissa ladulta
http://www.iki.fi/asb/ http://www.cs.helsinki.fi/u/abrax/hlb/

[1385 messages expunged from folder "Spam"]
.

Relevant Pages

  • Re: Showing exceptions on UML class diagram
    ... Should this exception class be shown on the diagram. ... ie CustomException is maybe part of a hierarchy. ... OTOH, if the object is a critical part of some unique exception handling strategy that is important to the problem in hand, then it should probably be explicitly identified along with the rest of the strategy. ...
    (comp.object)
  • Re: RFD: How To Recognize Bad Javascript Code
    ... error in the contents of one script element does not interfere with the successful interpretation/compilation of syntax error free code in other script elements within the same document. ... So any residual compatibility issue is really just in relation to very old web browsers; mostly the forth generation of browsers and their antecedents. ... javascript's try/catch construct is nearly totally useless for various reasons. ... In Java (and other languages with good exception handling support) you can be very specific about which exceptions you catch and handle. ...
    (comp.lang.javascript)
  • Re: Re: kern/99979: Get Ready for Kernel Module in C++
    ... in a jmpbuf -which are restored after a longjmp(). ... try/catch stores less. ... the instruction pointer and stack pointer, ... They are called "exception" ...
    (freebsd-hackers)
  • Re: Error handlers and Exception handlers
    ... There have been many a thread of the benefits of Try/Catch verses On Error, ... Otherwise I let my global exception handlers handle the event. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Exception in finally block
    ... try/finally inside of a try/catch. ... throw both XXException and IOException from processXX? ... and then rethrowing the exception. ...
    (comp.lang.java.programmer)