Re: Are throwing default constructors bad style, and if so, why?
Andre Kaufmann wrote:
analizer wrote:
On Sep 19, 1:28 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
a) A global object, which throws, will cause the application to
teminate / crash, without being able to handle the error.
What about to use singletons instead of "global objects"? Global
objects cause too many pitfalls such as initialization and linkage
orders etc. For singletons you can handle exceptions in c'tors
gracefully. Also this will allow to delay object initialization, it
will be initialized when it will be used first time.
Agreed. But there's too much code around simply using global objects and
singletons aren't that simple to handle in a multi threaded application.
I too don't use (complex) global objects, but unfortunately the world
isn't perfect ;-).
[...]
c) How many developers expect constructors to throw ?
All (ideally). If class method (including c'tor) throws exception,
then this should be reflected in code comments in header file. Anyone
who uses the class method should learn how this method works, for
example by reading comments to this method.
O.k. I agree, in modern C++ it's no problem to throw an exception in the
constructor and I would agree too that it's also a good style in modern
C++ to throw an exception in the constructor.
I only listed some problems, which might occur in old style, but still
common C++ code ;-)
I also agree it's fine and good style to throw from a constructor. I
only wonder (without being strongly convinced) whether throwing from the
constructor of an un-customized object is good.
Construction with parameters is a statement of intent. I, $DEITY, am
creating this object with specific parameters that give it personality
and make it "special", end expect the object to take shape according to
those parameters. If not possible, an exception is in order.
Construction without parameters seems in many cases to me a
"personalization to come later" statement, an as-of-yet-unexpressed
intent to make use of that object in accordance to its type, and also a
desire to keep options open and therefore preserve the object in an
inert state. Since often objects don't have all relevant data to fill
their subobjects during construction, I think it's only natural to
initialize them parameterlessly (and expect to not throw), to fill them
later on. Examples include all sorts of serialization scenarios
(including reading from databases, files, sockets, and so on). Also, if
you sorted a vector<deque<int> > and wanted to swap the pivot into a
temporary, is it reasonable for that temporary's non-argument
initialization to throw?
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]