Manage bad_alloc exception in C++ construtor

Question

I have Java experience and recently am doing some C++ coding. My question is that if I have class A, in which I have to instantiate class B and class C as two of the member variables of A.

If in the constructor of A, should I assume that allocations of class B and C never fail, and handle the bad allocation exception in the destructor of A?

If I don't make that assumption, meaning that I add some try catch block to catch bad_alloc of class B and class C, then if the allocation exception occurs, should I do clean up in the constructor of A?

What are the recommended practices? If "new" generates a bad allocation, what value does the pointer carry?

Answer 1

If an exception is thrown during the construction of A, your destructor will not be called.

Obviously the solution depends on what you're doing, but ideally you won't have to do any cleaning up. You should utilize RAII, and your class members should clean-up themselves.

That is, don't use any pointers raw; wrap them up and let the wrapper take care of it. Surprise! C++ programmers hate memory management just like you. We like to wrap it up and forget about it.

If you truly need to, though, I think this is common:

struct foo
{
    int* i;
    some_member_that_could_throw crap;

    foo() // do *not* new i! if the second member throws, memory is leaked.
    {     // rather:

        // okay we made it, the other member must have initialized
        i = new int;
    }
};

---

Concerning your pointer, it's value remains unchanged. When new throws an exception (for whatever reason), the stack is unwound. The rest of the expression is abandoned.

---

Here's how exceptions and object creation will work. It's a recursive process, because each member or base class will in turn follow this list. Fundamental types have no constructors; this is the base case for the recursion.

1. First, construct each of our base classes. (Which in turn run this list.)
2. Initialize members of the class, one by one.
3. Run the constructor body.
4. finish with a fully constructed object.

Obviously, if item 1 fails there isn't any cleaning up for us to do, as none of our members have been initialized. We're good there.

Two is different. If at any point one of those fails to construct , the initialized members so far will be destructed, then the constructor will stop progress and the exception goes on it's merry way. This is why when you let your members clean up after themselves you have nothing to worry about. The uninitialized have nothing to do, and the initialized are going to have their destructors run, where cleanup occurs.

Three even more so. now that your objects are fully initialized, you're guaranteed they will all have their destructors run. Again, wrap things up and you have nothing to worry about. However if you have a raw pointer lying around, this is the time for a try/catch block:

try
{
    // some code
}
catch (..) // catch whatever
{
    delete myrawPointer; // stop the leak!
    throw; // and let the exception continue
}

It's much messier to write exception-safe code without RAII.