Exceptions in constructors

Discussion in 'C++' started by tryptik@gmail.com, Sep 20, 2006.

  1. Guest

    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, 2006
    #1
    1. Advertising

  2. Kai-Uwe Bux Guest

    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
    Kai-Uwe Bux, Sep 20, 2006
    #2
    1. Advertising

  3. Daniel T. Guest

    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.
    Daniel T., Sep 20, 2006
    #3
  4. Phlip Guest

    Daniel T. wrote:

    > 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!!!
    Phlip, Sep 20, 2006
    #4
  5. mlimber Guest

    Kai-Uwe Bux wrote:
    > 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
    mlimber, Sep 20, 2006
    #5
  6. Daniel T. Guest

    "Phlip" <> wrote:
    > Daniel T. wrote:
    >> 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.
    Daniel T., Sep 20, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Rudolf
    Replies:
    12
    Views:
    8,251
    Martijn Lievaart
    Feb 6, 2004
  2. Jeremy Smith
    Replies:
    2
    Views:
    574
    Jeremy Smith
    Aug 3, 2006
  3. Jess
    Replies:
    5
    Views:
    583
    Ron Natalie
    Jun 7, 2007
  4. Peng Yu
    Replies:
    5
    Views:
    384
    Juha Nieminen
    Sep 19, 2008
  5. srp113
    Replies:
    3
    Views:
    456
Loading...

Share This Page