Re: Throwing exception in constructor
* James Kanze:
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.
Nope. One way to avoid "tests everywhere" was described in my previous
posting. More detailed explanation below.
In such cases, that one
particular argument in favor of exceptions in constructors is
more or less invalidated.
Nope.
(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:-).
No, and perhaps.
"No": assume P is a nullstate smart pointer holding a file object F.
This doesn't force the construction fauilure for F to propagate an
exception to client code, which can just check P for nullstate.
However, P guarantees that any attempt to use (features that requires a
successfully constructed) F results in a client code exception.
"Perhaps": I don't really buy the notion that exceptions should not be
used locally. If measurements show that this causes unacceptable
inefficiency, then it might be right to re-design or optimize. Doing so
as a matter of course would IMHO be evil premature optimization.
As an example, the Eiffel language's exception handling construct, a
kind of "loop until success or propagate the exception", is geared
directly towards local exception handling.
C++ makes this a tad more difficult to do in a clean way, but there are
solutions, e.g. the template pattern (I think it was Dave Harris who
came up with that application of the pattern in a discussion years ago;
I had argued for introducing something like Eiffel's feature in C++0x).
[snip]
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.
Yes, code generation ? la Java RMIC (Remote Method Invocation Compiler),
or for another example the various CORBA or SOAP tools, is very
convenient. I once considered making a code generator similar to RMIC
for interfacing Java to C++ COM classes; I thought I'd name it COMIC
(COM Invocation Compiler), and that was so cute I actually sat down and
wrote some initial code... :-p But such tools are limited.
The initialization order problem for C++ pops up when the original
object that was saved was of a class different from the class of the
reconstituted object, or when the information was not generated by
serialization of an object. For object-to-object, a requirement of
identical classes is the second of the solutions I mentioned in the
quoted passage above. I do not know why common C++ serialization
frameworks such as the ones in MFC and Boost don't make this
requirement, avoiding two-phase initialization.
A mismatch beteen the serialized data order and the C++ initialization
order can happen in (at least) the two ways mentioned above, with two
subcases for the first, for a total of (at least) three ways:
- The classes have different requirements. E.g., they live in
different programs and in program B you're only interested in a
subset of the information, and want to leverage other base classes.
- The requirements and classes have evolved; we're talking
versioned, backwards-compatible serialization here.
- The data did not originate from serialization of an object.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]