Dynamic memory and constructor exceptions_问答_开发者

Early today I discovered function try-catch blocks (from here in fact) and then went on a bit of a research spree - apparently they're main use is it catch exceptions throw in by a constructor initialiser list.

Anyway, this sent me thinking about failing constructors and I've got to a stage where I just need a little clarification. This is all just me trying to learn more about the language, so I don't have a practical example, but here goes...

Given this example code:

class A
{
private:
    B b
    C *c;    //classes B, C & D omitted for brevity as not really relevant
    D d;
public
    A(int x, int y, int z)
};

A::A(int x, int y, int z)
try
    : b( x )
    , c( new C(y) )
    , d( z )
{
    //omitted
}
catch(...)
{
    //omitted
}

What happens in these cases:

The initialisation of b throws an exception.
The initialisation of c throws an exception.
The initialisation of d throws an exception.

Specifically, I want to know at least:

what will/may cause a memory leak from new C(y). I'm thinking only 3? (see here)
could yo开发者_StackOverflowu just delete b in the catch? Is dangerous in cases 1 and 2?

Obviously, I guess the safest thing to do is to make c a smart pointer. But disregarding that option for the moment, what's the best course of action?

Is it safe to set c to NULL in the initialiser, and then place the call to new in the constructor body?

That would then mean a delete c must be placed in the catch in case something else throws in the constructor body? Are there safety issues doing that (ie, if it's the c = new C(y); itself that throws)?

Try/catch function blocks are frowned upon, in the same way as goto --there might be some corner case where they make sense, but they are better avoided: when an object fails to be constructed, best thing you can do is fail and fail fast.

On you specific questions, when an exception is thrown in a constructor, all fully constructed subobjects will be destroyed. That means that in the case of b it will be destroyed, in the case of c, it being a raw pointer, nothing is done. The simplest solution is changing c to be a smart pointer that handles the allocated memory. That way, if d throws, the smart pointer will be destroyed and the object released. This is not related to the try/catch block, but rather to how constructors work.

It is also, in general, unsafe to delete the pointer from the catch block, as there is no guarantee of the actual value of the pointer before the initialization is performed. That is, if b or c throw, it might be the case that c is not 0, but is not a valid pointer either, and deleting it would be undefined behavior. As always there are cases, as if you have a guarantee that neither b nor c will throw, and assuming that a bad_alloc is not something you usually recover from, then it might be safe.

Note that if you need to keep a pointer with a raw pointer for some specific reason, it is better to initialize it to 0 in the initialization list, and then create the object inside the construction block to avoid this problem. Remember also that holding more than one (raw) resource directly in a class makes it really hard to ensure that no resource is leaked -- if first resource is created and assigned, and the second one fails, the destructor will not be called and the resource will leak. Again, if you can use a smart pointer you will have one less problem to deal with.

You cannot do anything in the function-try-block handler, except translate one exception to another. You cannot prevent exception from being thrown. You cannot do anything to class members. So no, you cannot do delete c in the constructor's function-try-block.

The fully constructed base classes and members of an object shall be destroyed before entering the handler of a function-try-block of a constructor or destructor for that object.

and

The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. Otherwise, a function returns when control reaches the end of a handler for the function-try-block (6.6.3). Flowing off the end of a function-try-block is equivalent to a return with no value; this results in undeﬁned behavior in a value-returning function.

(15.3 [except.handle] from the C++ Standard)

To answer your actual question, any time an exception occurs during construction, execution stops right there (the object being constructed is never constructed) and control passes to the nearest exception handler (catch).

You're right that a memory leak will occur only when d causes an exception, and in that case, the outer catch needs to clean up.

If new C itself throws, the object is never constructed, so you don't need to worry about deleting it.