Acceptable answers for an interview question

Question

What kind of answers would you accept to the following question

"Describe the process and/or pitfall of throwing exceptions from constructor and destructors" (C++/C#/java)

What amount of knowledge about this would you consider essential, for a candidate claiming to have several years of experience in any of these languages (if he misses this, you almost certainly don't want him).

Answer 1

How about this (I am referring to C++): If an object throws within its constructor, the object may be left at an undefined state. The destructor will not run. This may lead to memory and handle leaks possibly even deadlocks.

Answer 2

He must know that in C++ the destructor is only called for fully constructed objects. So that the following class is leaky in C++:

class Leaky {
public:
    Leaky() { a = new char[100]; b = new char[100]; }
    ~Leaky() { delete a; delete b; }
private:
   char* a;
   char* b;
};

If exception is thrown while executing b = new char[100] then the Leaky::~Leaky() is not called and you've got a memory leak.

Answer 3

I don't believe this is a sensible question, at least nor with regard to the three languages mentioned. C++ has RAII, whereas the other two don't, so answers regarding C++ will be completely different.

Answer 4

Also, in C++, if an exception is unwinding the stack, and another exception is thrown from a destructor, the program will terminate (or, to be exact, call the terminate_handler).

Answer 5

Can't you put the constructor code in try-catch-finally block in C#? This way, if something goes wrong, the code in finally-section will free the resources.

Answer 6

This is kind of an edge question. For example, a competent developer will probably have figured out it's a bad idea somewhere along the line, and just avoids them. Frankly, the best I would've done on this is something like, well, it may leave the object in a partially constructed state, so it's generally best to avoid it." I would prefer to have them elaborate on what they do that's a good practice, and why.

Answer 7

If someone said they had 2 years of experience in C++ but didn't understand the ins and outs of constructors / destructors and exceptions, it would not prevent me from hiring them. This is the type of knowledge that can be easily learned and consists of a few simple rules.

I would certainly like them to have that knowledge but not having it does not make them a bad or lazy programmer. I've worked with excellent C++ programmers that spent the majority of their time in old school COM and HRESULT land. This makes heavy use of C++ but virtually eliminates C++ exceptions. There is no need or reason for them to have learned it. Once we introduced exceptions into the code base, it took about 15 minutes to get everyone on board with the constructor / destructor problem.

I would much rather use an interview to test a persons problem solving skills than to see if they knew the ins and outs of a particular part of C++. It is so easy to teach that, but so hard to teach problem solving.