Re: Throwing exception in constructor
Alf P. Steinbach wrote:
* kanze:
[...]
Anytime an
object can become invalid during its lifetime (and so later
tests of validity or success are necessary anyway), the argument
based on the absense of invalid objects looses its power.
Just a little. Mostly the argument is against an additional
nullstate (zombie state) /mixed in with other state/, which
must be checked everywhere, leading to complexity (a.k.a.
spaghetti) and bugs.
My point was only that for some object types, this "zombie"
state can come into being after successful construction, so you
need the tests everywhere anyway. In such cases, that one
particular argument in favor of exceptions in constructors is
more or less invalidated. (That doesn't mean that there might
not be others, and if the error condition is exceptional, and
probably cannot be handled locally, an exception might still
very well be in order.)
As an example, and this is a special case of a well-known
state pattern I forget the name of, access of an object
representing an open file can be restricted to a special kind
of smart-pointer so that the "real" object doesn't need to
deal with the nullstate, except notifying the containing smart
pointer of its further non-existence, and so that the
containing smart pointer only deals with (throwing exceptions
on operations on) nullstate: clean code in both classes, and
reusable generic nullstate.
Why isn't it ordinarily done that way?
Because that forces the error to be an exception, and most of
the time, you want to handle it locally:-).
Well, why am I currently fighting with triple-phase
initialization and other monstrosities? I think there's a
very strong tendency to design and code /locally/ for what the
slightly less than average programmer in the firm/shop/project
can be expected to understand and maintain. Then this
seemingly bright idea yields unmaintainable global spaghetti,
which in turn yields local spaghetti, 99.7% contrary to what
one aimed for.
That's certainly true, at least in general. Trying to make
something simpler than it really is usually ends up resulting in
the complexity getting tacked on later, rather than being
handled in the design. Isn't there a rule: make it as simple as
possible, but no simpler.
(Depending on the case, there may be other arguments for
exceptions in such cases. But it's not the cut and dried
case it would be otherwise.)
There are also probably a few rare cases (although I can't
think of any off hand) where it is justified to use a
factory function, which either separates initialization from
construction, or tests the success of the constructor, and
in case of failure, deletes the object and returns a null
pointer.
Ah, you're thinking of deserialization... ;-)
Maybe:-). To tell the truth, I wasn't thinking of anything in
particular. I was simply refusing the idea that such cases
couldn't exist.
At least, I've been thinking about it lately.
There is a conflict there between the initialization order
imposed by C++ and the order very strongly suggested by the
serialized data. One solution is buffering, another and
probably both more practical and efficient solution is to cast
the data member declaration order in stone for serializable
objects, and a third is to not regard the serialized data as a
stream, but as random access. Whatever solution one adopts
(and mostly it seems serialization frameworks, including the
one in Boost, choose none of these reasonable options and
instead go for ugly two-phase initialization) there is some
trade-off: that's engineering.
That's interesting. In every application I've worked on where
we needed serialization, we've used machine generated code to do
it. This sometimes ends up with a lot of extra classes: the
data declarations are generated by a program, and you derived a
second class to provide the behavior. But it seems to handle
the problem of ensuring that the order of serialization
corresponds to the order of declaration: you only write the
order once, and the program uses it for both serialization and
the declarations.
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]