Устранение исключений в конструкторах C++

Что касается ссылки на Google (вы не могли найти, как они обрабатывают ошибки в конструкторе):

Ответ на этот вопрос заключается в том, что если они выполняют только тривиальную работу в конструкторе, то ошибок нет. Поскольку работа тривиальна, они довольно уверены (подтверждено тщательным тестированием, я уверен), что исключения просто не возникнут.

Я предполагаю, что в значительной степени это зависит от того, какие типы исключений обычно возникают. Я предполагаю, что они в первую очередь связаны с ресурсами. Если это так, то решение, которое я использовал ранее во встроенной системе C, заключалось в выделении / фиксации всех потенциально необходимых ресурсов в начале программы. Таким образом, я знал, что все необходимые ресурсы были доступны во время выполнения, а не во время выполнения. Это жадное решение, которое может мешать взаимодействию с другим программным обеспечением, но оно сработало для меня довольно хорошо.

Если конструктор выполняет только тривиальные вещи, такие как инициализация переменных POD (и неявный вызов других тривиальных конструкторов), он не может потерпеть неудачу. См. C++ FQA; см. также почему вы не должны использовать исключения C++.

Обычно вы получаете такой код для объектов в стеке:

MyClassWithNoThrowConstructor foo;
if (foo.init(bar, baz, etc) != 0) {
    // error-handling code
} else {
    // phew, we got away with it. Now for the next object...
}

И это для объектов в куче. Я предполагаю, что вы переопределяете глобальный оператор new чем-то, что возвращает NULL вместо throw, чтобы спасти себя, не забывая везде использовать nothrow new:

MyClassWithNoThrowConstructor *foo = new MyClassWithNoThrowConstructor();
if (foo == NULL) {
    // out of memory handling code
} else if (foo->init(bar, baz, etc) != 0) {
    delete foo;
    // error-handling code
} else {
    // success, we can use foo
}

Очевидно, если вы можете, используйте интеллектуальные указатели, чтобы не запоминать удаления, но если ваш компилятор не поддерживает исключения должным образом, у вас могут возникнуть проблемы с получением Boost или TR1. Я не знаю.

Вы также можете захотеть структурировать логику по-другому или абстрагироваться от объединенных команд new и init, чтобы избежать глубоко вложенного «кода стрелки», когда вы обрабатываете несколько объектов, и для объединения обработки ошибок в двух случаях сбоя. Вышеупомянутое - это всего лишь основная логика в ее наиболее кропотливой форме.

В обоих случаях конструктор устанавливает все значения по умолчанию (он может принимать некоторые аргументы, при условии, что то, что он делает с этими аргументами, не может потерпеть неудачу, например, если он просто сохраняет их). Затем метод init может выполнять реальную работу, которая может дать сбой, и в этом случае возвращает 0 успехов или любое другое значение в случае сбоя.

Вероятно, вам нужно обеспечить, чтобы каждый метод инициализации во всей вашей кодовой базе сообщал об ошибках одинаково: вы делаете нет, чтобы некоторые возвращали 0 успехов или отрицательный код ошибки, некоторые возвращали 0 успехов или положительный код ошибки, некоторые возвращали bool, некоторые возвращали объект по значению, в котором есть поля, объясняющие ошибку, некоторую глобальную установку errno и т. д.

Возможно, вы могли бы быстро взглянуть на некоторые документы API классов Symbian в Интернете. Symbian использует C++ без исключений: у него есть механизм под названием «Leave», который частично компенсирует это, но выход из конструктора недействителен, поэтому у вас есть та же основная проблема с точки зрения разработки исправных конструкторов и отсрочки отказа. операции для запуска подпрограмм. Конечно, в Symbian подпрограмме инициализации разрешено оставить, поэтому вызывающей стороне не нужен код обработки ошибок, который я указывал выше, но с точки зрения разделения работы между конструктором C++ и дополнительным вызовом инициализации, это то же самое.

Общие принципы включают:

• Если ваш конструктор хочет получить значение откуда-то таким способом, который может привести к сбою, отложите это до инициализации и оставьте значение по умолчанию инициализированным в ctor.
• Если ваш объект содержит указатель, установите для него значение null в ctor и установите его «правильно» в init.
• Если ваш объект содержит ссылку, либо измените его на (умный) указатель, чтобы он мог начинаться с нуля, либо заставьте вызывающий объект передать значение в конструктор в качестве параметра вместо того, чтобы генерировать его в ctor.
• Если в вашем конструкторе есть элементы объектного типа, все в порядке. Их ctors тоже не будут выбрасывать, так что вполне нормально создавать ваши члены (и базовые классы) в списке инициализаторов обычным способом.
• Убедитесь, что вы отслеживаете, что установлено, а что нет, чтобы деструктор работал при сбое инициализации.
• Все функции, кроме конструкторов, деструктора и init, могут предполагать, что init завершился успешно, при условии, что вы документально подтвердили для своего класса, что нельзя вызывать какой-либо другой метод, кроме init, до тех пор, пока init не будет вызван и не завершится успешно.
• Вы можете предложить несколько функций инициализации, которые, в отличие от конструкторов, могут вызывать друг друга точно так же, как для некоторых классов вы предлагаете несколько конструкторов.
• Вы не можете предоставить неявные преобразования, которые могут потерпеть неудачу, поэтому, если ваш код в настоящее время полагается на неявные преобразования, которые генерируют исключения, вам необходимо изменить дизайн. То же самое касается большинства перегрузок операторов, поскольку их возвращаемые типы ограничены.

Если вы действительно не можете использовать исключения, вы также можете написать макрос построения, который всегда будет делать то, что кто-то предлагает. Таким образом, у вас не будет проблем с постоянным выполнением этого цикла создание / инициализация / если и, что наиболее важно, вы никогда не забудете инициализировать объект.

struct error_type {
    explicit error_type(int code):code(code) { }

    operator bool() const {
        return code == 0;
    }

    int get_code() { return code; }
    int const code;
};

#define checked_construction(T, N, A) \
   T N; \
   if (error_type const& error = error_type(N.init A))

Структура error_type инвертирует условие, чтобы ошибки проверялись в части else if. Теперь напишите функцию инициализации, которая в случае успеха возвращает 0 или любое другое значение, указывающее код ошибки.

struct i_can_fail {
    i_can_fail() {
        // constructor cannot fail
    } 

    int init(std::string p1, bool p2) {
        // init using the given parameters
        return 0; // successful
    } 
};

void do_something() {
    checked_construction(i_can_fail, name, ("hello", true)) {
        // alright. use it
        name.do_other_thing();
    } else {
        // handle failure
        std::cerr << "failure. error: " << error.get_code() << std::endl;
    }

    // name is still in scope. here is the common code
}

Вы можете добавить в error_type другие функции, например, то, что проверяет значение кода.

Вы можете использовать флаг, чтобы отслеживать, не удалось ли конструктору. Возможно, у вас уже есть переменная-член, которая действительна только в случае успешного выполнения конструктора, например

class MyClass
{
public:
    MyClass() : m_resource(NULL)
    {
        m_resource = GetResource();
    }
    bool IsValid() const
    {
        return m_resource != NULL;
    }
private:
    Resource * m_resource;
};

MyClass myobj;
if (!myobj.IsValid())
{
    // error handling goes here
}