By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,084 Members | 1,969 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,084 IT Pros & Developers. It's quick & easy.

Exceptions in constructors

P: n/a
All-

I have heard differing points of view on whether or not constructors
should throw. I am working on a library, and I need to know if it is
bad form for a consturctor to throw.

Thanks
-J

Sep 20 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
tr*****@gmail.com wrote:
All-

I have heard differing points of view on whether or not constructors
should throw. I am working on a library, and I need to know if it is
bad form for a consturctor to throw.
Throwing from a constructor is fine. The alternative is to have the
constructor leave the object in an inconsistent state, which is rarely the
better way to go about the problem.
Best

Kai-Uwe Bux
Sep 20 '06 #2

P: n/a
tr*****@gmail.com wrote:
I have heard differing points of view on whether or not constructors
should throw. I am working on a library, and I need to know if it is
bad form for a consturctor to throw.
Destructors should never throw. Constructors should throw if they cannot
put the object into a valid state.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.
Sep 20 '06 #3

P: n/a
Daniel T. wrote:
tr*****@gmail.com wrote:
>I have heard differing points of view on whether or not constructors
should throw. I am working on a library, and I need to know if it is
bad form for a consturctor to throw.

Destructors should never throw. Constructors should throw if they cannot
put the object into a valid state.
And all objects should be ready for unit tests. Unit tests often require
objects in a minimally constructed state, without all their baggage. So a
constructor should not sub-construct everything it could possibly use,
because a unit test will just throw it all away.

This isn't just an optimization issue - lean constructors are a sign of
clean designs, and of "construction encapsulation".

So the best constructors, following this guideline, are those that do the
minimum to prevent their next expected method, or their constructor, to not
crash. Set your pointers to NULL and return. No hard logic, so no
exceptions.

This guideline has plenty of harmless contradictions; they represent
applying more theory to this basic theory.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 20 '06 #4

P: n/a
Kai-Uwe Bux wrote:
tr*****@gmail.com wrote:
All-

I have heard differing points of view on whether or not constructors
should throw. I am working on a library, and I need to know if it is
bad form for a consturctor to throw.

Throwing from a constructor is fine. The alternative is to have the
constructor leave the object in an inconsistent state, which is rarely the
better way to go about the problem.
Right, as usual. To back you up, here's a quote from _C++ Coding
Standards_ by Sutter and Alexandrescu, Item 72:

"Exception handling is better than the alternatives for reporting
errors from constructors and operators: The copy constructors and the
operators have predefined signatures that leave no room for return
codes. In particular, constructors have no return type at all (not even
void), and and for example every operator+ must take exactly two
parameters and return one object (of a prescribed type; see Item 26).
For operators, using error codes is at least possible if not desirable;
it would require errno-like approaches, or inferior solutions like
packaging status with an object. For constructors, using error codes is
not feasible because the C++ language tightly binds together
constructor exceptions and constructor failurs so that the two have to
be synonymous; if instead we used an errno-like approach such as

SomeType anObject; //Construct an object
// Test whether construction worked
if( SomeType::ConstructionWasOk() ) {
// ...

then not only is the result ugly and error-prone, but it leads to
misbegotten objects that don't really satisfy their type's
invariants--never mind the race conditions inherent in calls to
SomeType::ConstructionWasOk in multithreaded applications. (See
[Stroustrup00] E.3.5.)"

BTW, that section in Stroustrup can be found here for free:

http://www.research.att.com/~bs/3rd_safe.pdf

See also this GotW:

http://www.gotw.ca/gotw/066.htm

Cheers! --M

Sep 20 '06 #5

P: n/a
"Phlip" <ph******@yahoo.comwrote:
Daniel T. wrote:
>tr*****@gmail.com wrote:
>>I have heard differing points of view on whether or not
constructors should throw. I am working on a library, and I need
to know if it is bad form for a consturctor to throw.

Destructors should never throw. Constructors should throw if they
cannot put the object into a valid state.

And all objects should be ready for unit tests. Unit tests often
require objects in a minimally constructed state, without all their
baggage. So a constructor should not sub-construct everything it
could possibly use, because a unit test will just throw it all away.

This isn't just an optimization issue - lean constructors are a sign
of clean designs, and of "construction encapsulation".

So the best constructors, following this guideline, are those that
do the minimum to prevent their next expected method, or their
constructor, to not crash. Set your pointers to NULL and return. No
hard logic, so no exceptions.
Agreed except that IMHO, "their next expected method" should actually
read "any of their methods".

I'm not a big fan of empty shell objects that need reams of
initialization calls before they can be used for their purpose.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.
Sep 20 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.