According to Herb Sutter the code below wouldn't compile. See this site http://www.gotw.ca/gotw/066.htm from where I've extracted the following text, regarding function-try-blocks :

Toward Some Morals

Incidentally, this also means that the only (repeat only) possible use for a constructor function-try-block is to translate an exception thrown from a base or member subobject. That's Moral #1. Next, Moral #2 says that destructor function-try-blocks are entirely usele--

"--But wait!" I hear someone interrupting from the middle of the room. "I don't agree with Moral #1. I can think of another possible use for constructor function-try-blocks, namely to free resources allocated in the initializer list or in the constructor body!"

Sorry, nope. After all, remember that once you get into your constructor try-block's handler, any local variables in the constructor body are also already out of scope, and you are guaranteed that no base subobjects or member objects exist any more, period. You can't even refer to their names. Either the parts of your object were never constructed, or those that were constructed have already been destroyed. So you can't be cleaning up anything that relies on referring to a base or member of the class (and anyway, that's what the base and member destructors are for, right?).

Assuming this quote, the following code should not compile, as the object cat has already been destructed by the time the process runs into the catch clause. But it does, at least with VSC2008.

class Cat
{
    public:
    Cat() { cout << "Cat()" << endl; }
    ~Cat() { cout << "~Cat()" << endl; }
};

class Dog
{
    public:
    Dog() { cout << "Dog()" << endl; throw 1; }
    ~Dog() { cout << "~Dog()" << endl; }
};


class UseResources
{
    class Cat *cat;
    class Dog dog;

    public:
    UseResources();
    ~UseResources() { delete cat; cat = NULL; cout << "~UseResources()" << endl; }
};

UseResources::UseResources() try : cat(new Cat), dog() { cout << "UseResources()" << endl; } catch(...)
{
    delete cat;
    throw;
}
3

There are 3 answers

0
UncleBens On BEST ANSWER

I don't think Herb Sutter is actually saying that it won't compile. He is just explaining the consequences of what the standard has to say about the situation (15.3.10):

Referring to any non-static member or base class of an object in the handler for a function-try-block of a constructor or destructor for that object results in undefined behavior.

3
stdcall On

Compilers are different, and also there are switches that determine how much the compiler will be strict with the code it's compiling. this code will certainly cause errors (seg faults, etc). try to enable all the switches of the compiler to force it to find this.

2
John Feminella On

Assuming this quote, the following code should not compile...

Well, he didn't say they would never compile. If anything, I interpreted the quote to mean "doing this is undefined". Undefined behavior is allowed to have any result -- up to and including compiling successfully, and doing surprising things later on.