Re: Throwing Constructor Exceptions and cleaning up
Richard Maher wrote:
c) It's considered extremely bad form to do this in a constructor.
Have an
init() method instead?
Peter Duniho wrote:
There are too many examples of constructors that do throw exceptions for
me to think it's always considered "extremely bad form"
In another thread it was averred that one of the motivations to have
exceptions in a language is to throw them from constructors.
The fact is, just because you throw an exception in the constructor,
that's no guarantee that the object can be GC'ed. It _should_ be, but
you can in fact pass the "this" reference out of the constructor,
allowing it to be held elsewhere, causing the object to be reachable
even though the constructor failed.
One reason why it's bad practice to let 'this' escape the constructor.
But, assuming you write code that's more robust than that, then it's up
to you to ensure any cleanup is done if necessary. Ideally, you'd do
all the things that could throw an exception either outside the
constructor or before doing anything that'd need cleaning up. But
that's not always possible.
One thing that helps is to limit constructors to those tasks directly involved
with instance construction, and not those that do the job of the instance.
IOW, the pattern should not be to do a 'execute()' within the constructor but
to do 'new Foo().execute()'.
I admit, I'm not completely familiar with how the Java run-time manages
the finalizer. ...
But as near as I can tell, in Java every object has a finalize() method
(duh), and that method is always executed before the object is GC'ed,
Not exactly.
requiring the GC to always check the object at least twice for
Not true.
collection. I suppose maybe the run-time looks to see if the method has
been overridden, and only calls it if it has.
That's how it's done. When an object has a "non-trivial" finalizer, the JVM
registers it as such on construction. Only those objects need two GC cycles
to clean up - the first to run 'finalize()' and the second to reclaim the
space. Trivial (do-nothing) finalizers are not run, so those objects with
trivial finalizers only need one GC cycle. That's part of the cost of
overriding 'finalize()' non-trivially.
This is covered in the JLS (amazingly) in s. 12.6.
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.6>
Either Bloch covers the dangers and costs of finalizing in /Effective Java/,
or Goetz does in a DeveloperWorks article, or both - my recollection on that
is dim. Google if interested.
--
Lew