Why can't constructors gracefully handle errors?

Question

I read the following

The inability to gracefully handle errors in C++ constructors is one good reason to avoid constructors that do more than nothing, and use initialization functions instead. And C++ exceptions are not a graceful way to handle errors, especially in constructors. If your member object constructor throws an exception, and you want to catch it in your constructor, the normally ugly colon syntax gets much uglier.

I would like to know why constructors can't gracefully handle errors ? Constructors can still support try-catch so why is it that constructors can't gracefully handle errors ?

Answer 1

I would like to know why constructors cant gracefully handle errors ?

They can, by throwing an exception if initialisation fails.

This is far more "graceful" than the suggestion to leave the object in a half-alive state, to be properly initialised by calling a function later. Used correctly^[1], exceptions guarantee that the object is either fully initialised, or doesn't exist.

This advice presumably comes from someone who disapproves of the use of exceptions to report error conditions; in which case C++ does indeed become an extremely clumsy language, with no convenient way to express initialisation failure. Fortunately, the use of exceptions is idiomatic among most C++ programmers, so there's usually no need to pay attention to this kind of nonsense.

_{[1] Specifically, in conjunction with RAII, to avoid the need to "catch it in your constructor" or anywhere apart from the error handler itself.}

Answer 2

I think "gracefully handling errors" is subjective...

Anyway, probably the author is thinking of something like:

class X
{
private:
   int * v1; // a vector of int's, dynamically allocated
   int * v2; // another vector of int's, dynamically allocated

public:
    X() 
    {
        v1 = new int[...];
        .... do something

        v2 = new int[...];
        ... If this throws, then v1 is leaked, since destructor is not called for X

        ...
    }
};

Actually, I think that if you proper use RAII and RAII building-blocks, there are no problems, and constructor can handle errors gracefully (for some meaning of "gracefully").

In the above example, if you replace the raw dynamically-allocated arrays with a RAII building-block like std::vector, you have no problems, since destructors are called on data members if an exception is thrown in the constructor of class X (even if the destructor for X is not called):

class X
{
private:
   std::vector<int> v1;
   std::vector<int> v2;

public:
    X() 
    {
        v1.resize(...);
        .... do something

        v2.resize(...);
        // If this throws, then v1 is NOT leaked, 
        // since the destructor is called for v1 data member

        ...
    }
};

Anyway, there are cases in which you just don't want the constructor to throw, e.g. a file class, in which you can have an IsOpen() member function to check if the file was opened successfully in the constructor (instead of having the constructor throwing an exception if file open fails).
This is just a matter of personal design preference.