What is the best way to handle a constructor failure?

I assume your using return codes or something similar to handle errors, as constructors cant return anything. Check out exceptions, theres a new tutorial about it on good ole gamedev about it:

http://www.gamedev.net/reference/programming/features/exceptionquest

Theres also one on flipCode as well - i advise you read both of them. Exceptions are v useful.

check this out:
constructor result
this will show you how to get the result of a failure/succeed of a constructor

Arkon
[QSoft Systems]

?????? Arkon... the code you referenced throws an exception at the end of the class''s constructor!??? ... Wouldn''t that mean that the class will never be constructed... since C++ would see the throw at the end of _test::_test() as an exception and abort immediately. Why would you ever want to do that??

Constructors aren''t suppose to have a result, they either work and construct the class, or they dont. If you have some special information that needs to be returned, you''re much better off to store it in a private member variable and provide another member function to give you the result, or just put it in a public member variable.

ex:

class _test
{
public:
_test();
~_test();

int constructor_result;
};

_test::_test()
{
// DoSomething() and set constructor_result;
}


if you''re talking about handling an error while constructing a class, then yes you want to throw an exception, but only for the error, you dont want to be throwing exceptions if the class is constructed properly.

well i use it as a return...

Arkon
[QSoft Systems]

use an exception as a return ?? .

thats a good idea if the constructor has an error..

just remember to put a delete in your catch statement to delete the object if the constructor throws an exception.

thats assuming the object is a heap and created with new ..



{ Stating the obvious never helped any situation !! }

Ok ... I just HAVE to make a few statements here ...

There are exactly 2 ways to deal with an unexpected situation or error during a constructor in C++. They have different benifits and the C++ standard library uses both in different places for different reasons. Here they are:

1) If the item can be meaningfully created, but some portion of it''s functionality will not be available ... then it is possible to store this situation in a private data member that the user must check ... and they MUST be taught to check this value prior to using the class ... this is the way files in C++ work. You construct one, but if there is an error and the file cannot be opened, then the user will notice that when he calls myFile.fail() and gets a true value. IMPORTANT NOTE: this situation is ONLY to be used when part of the class is still usable and/or the error may be corrected my the user making other calls after the construction (such as explicitly calling open() with possibly different values). As note that this was chosen in the file example, primarily because it does not cause an invalid state that files did not already have ... they already supported being opened or closed ... so it was easy to just consider this a closed file.

2) If the constructor cannot create an object that behaves according to it''s documentation, or if it would be too inefficient to support every function handling every possible object state ... then you need to throw an exception. This IS the official C++ means of dealing with a constructor error. In fact this is the ONLY way of signaling an out-of-memory error, or many other similar situations that you cannot deal with reasonably.

Number 2 works like this: 1) if they construct an object on the stack ... and it fails ... an exception is thrown .... all''s well, 2) if they use the standard new operator and the constructor fails ... the exception is thrown ... all''s well 3) if they use the nothrow version of new to construct the object ... and the object fails .. .then the nothrow new operator catches the exception, and returns NULL ... all is well ... so you see ... this is the ONLY way to really handle bad constructors that behave like all of the built in and standard types - and there is NO unexpected side effect .. and no user learning curve - they already expect failed constructors to throw exceptions or return NULL ... and that''s just what your''s will do.

I hope that clears everything up ... also ... if the error in question is based on a lack of memory ... or a build in type''s constructor failing .. the standard exception type is bad_alloc .. so you should use this same type when appropriate.

Good Luck.