Re: Clean up after exception thrown in constructor
Philipp wrote:
PS: Could someone recommend some reference about why exceptions in
constructors are bad. In particular, if the constructor has no side
effects, I can't understand what the problem is in having exceptions.
Peter Duniho wrote:
I can't either. :)
Seriously though, lots of classes in the Java SDK can throw exceptions
from the constructor. I didn't read any of the messages in this thread
as being anti-exception in a constructor. Just anti-side-effects. And
of course it seems as though you _do_ understand at least some of why
side-effects in a constructor are bad (frankly, they're not great
anywhere, but it seems to me they are especially non-optimal in a
constructor).
...
I don't personally think that there's anything fundamentally wrong with
throwing an exception from a constructor. After all, every "new" can
potentially throw at least one exception (out-of-memory). And throwing
an exception from a constructor is the only way to report an error (be
it an invalid parameter, some problem with the current state of the
program, etc.)
I agree, throwing an exception from a constructor is perfectly legitimate if
properly documented. One problematic area is constructors that are invoked
reflectively, as via a framework or to load a driver. The framework must
expect the exceptions that can be thrown; if it assumes none can be and the
constructor throws one, it would be trouble.
Philipp wrote:
In fact, I will follow the advice of several and add a register() method which
can handle the exception properly. Naturally, this puts the burden of calling
register() and remove() at the right moments on the programmer.
You can assist the client code with checks for proper state in the service
methods. If register() has not been called yet, then doWork() can throw an
IllegalStateException. Calling on an improperly initialized object is a
programming error, so a runtime exception is appropriate.
Even though runtime exceptions are not declared in the method signature, you
should still document them with an '@throws' in the Javadoc.
--
Lew