Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Exceptions in constructors

Reply
Thread Tools

Exceptions in constructors

 
 
tryptik@gmail.com
Guest
Posts: n/a
 
      09-20-2006
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

 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      09-20-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
 
 
 
Daniel T.
Guest
Posts: n/a
 
      09-20-2006
(E-Mail Removed) 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.
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      09-20-2006
Daniel T. wrote:

> (E-Mail Removed) 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!!!


 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      09-20-2006
Kai-Uwe Bux wrote:
> (E-Mail Removed) 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

 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      09-20-2006
"Phlip" <(E-Mail Removed)> wrote:
> Daniel T. wrote:
>> (E-Mail Removed) 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reg constructors/copy constructors inheritance srp113 C++ 3 02-17-2009 04:01 PM
Is the possible to have all the public constructors of the publicbase class as the constructors of a derived class? Peng Yu C++ 5 09-19-2008 10:19 AM
compiler synthesized constructors/copy constructors/assignment operators Jess C++ 5 06-07-2007 11:09 AM
Copy constructors, de/constructors and reference counts Jeremy Smith C++ 2 08-02-2006 11:25 PM
Constructors that call other Constructors Dave Rudolf C++ 12 02-06-2004 03:26 PM



Advertisments