Re: Throwing Constructor Exceptions and cleaning up

Arne Vajhøj wrote:
Richard Maher wrote:
For me, the important bits were: - finalize() is really just belt-and-braces
and not a destructor, everything is GC'ed at process exit,

Note that finalizers will not necessarily be run at JVM exit.

It will only be guaranteed if System runFinalizersOnExit is called.

And that method is deprecated in every sense of the word.

> and you gotta
clean-up after yourself, there's no magic-wand or guaranteed
rundown-handler.

Yep.

Try catch finally and do the right thing.

Remember that finally executes on any exit from the try block, including success (fall out or return from inside it, or break or continue from inside it to outside it).

Something like this will work:

public class MyClass {
private final InputStream wrapped;

public MyClass (int arg1) throws IOException {
if (arg1 < 0) throw new IllegalArgumentException();
boolean success = false;
InputStream w = null;
try {
w = new FileInputStream(getFile(arg1));
someSetupStuffThatMayThrow();
wrapped = w;
success = true;
} finally {
if (w != null && !success) w.close();
}
}

private static File getFile (int arg1) { ... }
private static void someSetupStuffThatMayThrow ()
throws IOException { ... }
}

The finally block cleans up by closing the InputStream only if a success flag wasn't put up at the end of the try body (and only if the stream itself was opened successfully).

If the input stream can b0rk and the object (or at least the stream) is useless once this has occurred, every method that uses the stream may wish to catch IOException, close the stream, and rethrow. The object might wish to make all future operations (at least involving the stream) fail fast with a non-checked exception after this; simply setting the stream to null works (if it's not final; it is in the example above).

The constructor however has to deal with the possibility of any exception at all, not just ones that invalidate the stream, because unhandlable ones will invalidate the whole object. This includes OOME or other Errors. Hence the need for a finally block that cleans up under every circumstance other than a clear success. Maximum safety occurs if putting the success flag up is the last thing done before the try body exits, and nothing is done after the try body (and the finally body) except to fall out of the constructor.
.

Relevant Pages

  • Re: Throwing Constructor Exceptions and cleaning up
    ... I should not have gotten rid of the 'success' flag. ... public MyClass (int arg1) throws IOException ... exceptions from 'someSetupStuffThatMayThrow' and close the stream. ...
    (comp.lang.java.programmer)
  • Re: feof(), fseek(), fread()
    ... An input stream can be connected to the user's ... with varying degrees of success. ... fgetc() could have used a trick to report "end of file" ... Now, about that fourth item, the "EOF character" ... ...
    (comp.lang.c)
  • Re: GOTO statement and return results way
    ... You had different expectations in a computer programmers' forum? ... I feel the Exit Try makes it more ... sub method ... If Success Then ...
    (microsoft.public.dotnet.languages.vb)
  • Re: zombie process questions
    ... stream and forks, ... output buffers which are copied to the child on forkare flushed ... "The _Exit() and _exitfunctions shall not call functions registered ... C++ static destructors are executed in the correct order. ...
    (comp.unix.programmer)
  • Re: how to remove code duplication
    ... the log directory should containing the same files as the out ... exit(EXIT_FAILURE); ... int main ... void process_log_data(FILE *stream) ...
    (comp.lang.c)