Russian Qt Forum

Доброго времени.

У меня тут назрела небольшая непонятка: как прервать конструктор класса , если в нем произошла какая-либо ошибка?
т.е. нужно в таком случае сделать так, чтобы конструктор вернул НУЛЬ. ,
например:

т.е. чем прерывать конструктор?:
1. делать в нём return; ?
2. вызывать деструктор?
3. или как ?

Конструктор можно прервать исключением.
Если не хочешь/не можешь использовать исключения, то можно использовать внутренний флаг валидности объекта. И проверять его после конструирования.
bool MyClass::isValid() const;

в конструкторе, крайне нежелательно писать код, который может выполнится неправильно.

т.е. имеется ввиду что-то вроде:


???


дык а если я в конструкторе класса создаю приватные объекты для этого класса, то как мне узнать что они создались корректно? если у них нет возможности проверить флаг валитности и т.п. то как быть?

Угу, оно самое.

дык а если я в конструкторе класса создаю приватные объекты для этого класса, то как мне узнать что они создались корректно? если у них нет возможности проверить флаг валитности и т.п. то как быть?

т.е. если я создаю к примеру в конструкторе MyClass::Myclass():


то как я узнаю, что notifier  создался правильно? ведь по-любому оператор new вернет указатель на память объекта - НО это не факт, что внутри у себя там объект проинициализировался корректно!

Опиши конкретнее ситуацию. Пример желателен.

пример:

*.h

*.cpp

вот чисто "гипотетический пример" , вместо таймера можно что угодно подставить :)

Пересмотри архитектуру, поизучай классы Qt, посмотри, как там сделано. Конкретно, вынеси из конструктора код, который может засбоить или используй флаг, это тебе уже говорили выше.

Обычно так

Хотя в Qt это не принято  :)

ок, спс.. будем разбираться

Я с опаской отношусь к прирыванию конструтора... Лучше разнести создание обьекта и инициализацию.

Возбуждение исключения - самый правильный и надёжный способ в С++ прервать конструктор и сообщить что произошла ошибка.
При этом автоматом вызываются деструкторы  членов и базовых классов.
Естественно нужно позаботится об освобождение явно выделенных в конструкторе ресурсов.
Для этого можно модифицировать твой пример 2-мя способами:
 1. Использовать "умный" указатель для поля QTimer *timer.
Любой понравившийся из распространённых:
QPointer<QTimer> timer, std::auto_ptr<QTimer> timer, boost::scoped_ptr<QTimer> timer.
 2. Использовать "умные" указатели только внутри коснтруктора.
Для этого код коснтруктора разбивается на 2 области - реальная инициализация во временные переменные где может случится облом и установка полей, где обломов быть не может:

C++ (Qt)
Myslass::Myslass(QObject *parent)
    : QObject(parent), timer(0), notifier(0)
{
    //Здесь могут происходить обломы
    std::auto_ptr<QTimer> timer = new QTimer(this);
    if (otherSomethingWrong)
        throw MyException();
    std::auto_ptr<QSocketNotifier> notifier = new QSocketNotifier (this);
    ....
    //Здесь обломов уже быть не может
    this->timer = timer.release();
    this->notifier = notifier.release();
}
 

В отличии от всяких флагов валидности, оба подхода гарантируют корректное освобождение ресурсов и защищают от работы с невалидным объектом

Вместо QPointer лучше QWeakPointer.

Я не согласен с тем, что флаг валидности плохое решение. Если QWeakPointer действительно сможет отлавливать невалидные объекты, то исключения тут даже не нужны, жертвовать переносимостью ради удобства лично я не буду.

Не видно проблем переносимости т.к. исключения входят в стандарт языка. По поводу "флага валидности" - может и не плохо но что хорошего в нем мало - это точно. Поймать невалиднось и установить флаг легко, трудно с этим дальше работать. От объекта чего-то хотят, зовут его методы и.т.п. А тут выясняется что этот метод "не имеет должного эффекта" т.к. объект-то невалиден и обеспечить эту ф-циональность не может. А унаследовался от такого объекта - проверки валидности лезут в новые/перекрытые методы. В общем все это начинает неприятно быстро расползаться.

дадада.. + пицот

Сомневаюсь, что большинство программистов используют try{} catch() везде где только возможно или даже проверяют коды возвратов где это возможно. Поэтому работа с невалидным объектом обычное дело. К тому же многое зависит от того что понимать под валидностью. Одно дело, когда памяти не хватает под объект и совсем другое, когда например отсутствует файл на диске, который попытались открыть в конструкторе класса. Но даже в последнем случае обычно дублируют функционал в виде метода типа MyClass::setFile().

isValid() никуда не расползается, он остается там где его поместили. Если базовый класс не валиден, то и наследник тоже. Если нужно обеспечить валидность на всех уровнях наследования делают виртуальный метод или адаптер.

RTTI тоже входит, только его особо не жалуют. Много чего входит, только оно еще не реализовано или не везде.

А есть ли в qt конструкторы, которые выбрасывают исключения?

Только там, где они поддерживаются.

C++ (Qt)
/* These wrap try/catch so we can switch off exceptions later.
 
   Beware - do not use more than one QT_CATCH per QT_TRY, and do not use
   the exception instance in the catch block.
   If you can't live with those constraints, don't use these macros.
   Use the QT_NO_EXCEPTIONS macro to protect your code instead.
*/
 
#ifdef QT_BOOTSTRAPPED
#  define QT_NO_EXCEPTIONS
#endif
#if !defined(QT_NO_EXCEPTIONS) && defined(Q_CC_GNU) && !defined (__EXCEPTIONS) && !defined(Q_MOC_RUN)
#  define QT_NO_EXCEPTIONS
#endif
 
#ifdef QT_NO_EXCEPTIONS
#  define QT_TRY if (true)
#  define QT_CATCH(A) else
#  define QT_THROW(A) qt_noop()
#  define QT_RETHROW qt_noop()
#else
#  define QT_TRY try
#  define QT_CATCH(A) catch (A)
#  define QT_THROW(A) throw A
#  define QT_RETHROW throw
#endif
 
 

C++ (Qt)
QWidget::QWidget(QWidget *parent, Qt::WindowFlags f)
    : QObject(*new QWidgetPrivate, 0), QPaintDevice()
{
    QT_TRY {
        d_func()->init(parent, f);
    } QT_CATCH(...) {
        QWidgetExceptionCleaner::cleanup(this, d_func());
        QT_RETHROW;
    }
}
 

ужос :o
вам бы на Си писать. или на чем-то подобном.

снова ужос :o

подавляющее большинство программеров, не используют исключения, т.к. не знают/не понимают в чем их плюсы.
а коды ошибок..что тут понимать, оверхедим/хардкодим кучу проверок условий, 20 ифов, или свичь на все случаи жизни ;D
ппц одним словом.
да, Qt приучает так кодить ;)

"Большинство программистов" где? На этом форуме? На Qt? Или "в мировом масштабе"?  :) Я гораздо чаще сталкивался с другой крайностью - неумеренное (на мой взгляд) испускание exception, даже там где спокойно можно обойтись кодом возврата. Все хорошо в меру и спорить не о чем. Сам пробовал оба пути, мое мнение пусть не всегда, но частенько с exception получается значительно короче и чище.

в мировом масштабе. чаще всего, такое наблюдаю у тех программистов, которые учатся программировать, используя фреймворк, типа Qt. А должны, прочтя несколько книжек из классики с++.

try{} catch() - предназначены для обработки !исключительных ситуаций!. да, иногда встречается перебор, но в процентном соотношении, это около 10 процентов от кол-ва оверхеда при проверке результатов/флагов.

niXman
особенно "исключительная" ситуация - файл занят другой программой при открытии его на чтение (c#). Любите эксепшны...

Исключительная ситуация - это та, которую невозможно решить на данном уровне абстракции.
Например, для XML-парсера, невозможность прочитать из потока закрывающий тег - исключительная ситуация.
Т. к. по стандаоту он должен прервать обработку в случае невалидности.

И ловить брошенное исключение нужно не в каждом месте, где оно может пролетать, а только там, где есть информация и возможность для принятия решения что же с ним делать.
Например, если с помощью XML-я добываются данные для отображения текущей погоды на биржах, то ловить исключение о невалидности XML-пакета следует там, где мы можем решить перезапрашивать данные опять или продолжать показывать старые. :)
Ловить до этого места смысла не имеет - там нет возможности принять решение что же с ним делать.

Поэтому, в хорошем коде довольно мало мест, где встречается конструкция try...catch.
Их может быть в разы, а то и на порядок меньше чем мест, где бы пришлось проверять флаги завершения и валидности. :)
Код получается компактнее и нагляднее.
Правда с исключениями обязательно нужно использовать технику RAII (http://ru.wikipedia.org/wiki/RAII) иначе уродства типа показанного SABROG-ом (http://www.prog.org.ru/index.php?topic=13051.msg84841#msg84841) и более навороченных не избежать.

Вообще многое от культуры программиста зависит. Я очень долго отучал коллегу от catch(...) везде, где только можно, "Чтобы ошибку не выводило."
В хорошем коде должно быть много мест, где обрабатываются ошибки, не важно как они сообщаются ;)
А ещё объясните, как при использовании RAII обрабатывать исключения и ошибки в деструкторах. Вот с кодами возврата всё ясно, а с исключениями - сразу падение программы :)

PS: Я не против исключений, я за разумный подход в выборе метода сообщения об ошибках :)

то ли я не понял RAII то ли я тупой:)
а) какая связь между количеством исключений и тем, как создаются/освобождаются ресурсы.
б) смысл RAII - в том чтобы, о боже, освобождать ресурс в деструторе? А кто-то так не делает? по-моему знание "паттернов" только мешает жить, они все такие гениальные...

Одно из свойств RAII это как раз гарантированное освобождение ресурсов при выходе из зоны видимости. Поэтому, если происходит исключение ресурсы гарантированно освободятся.

В паттернах ничего гениального нет, при программировании ты рано или позно придешь к этим приемам сам.
Их достоинство в систематизации этих приемов.

я бы сказал это единственное его свойство:)
в том-то и проблема что я гляжу на каждый новый паттерн и удивляюсь "а чо тут такого гениального"

Никто никому не гарантирует освобождение ресурсов, даже вызов деструктора не всегда гарантируется. ;)

Скажем так, гарантирует вызов деструктора, а вот с освобождением ресурса... тут от ресурса зависит.  :)

Про деструкторы и исключения - исключения из деструктора вылетать не должно.
Т. е. все действия, которые могут повлечь генерацию исключения нужно делать либо в конструкторе, либо явно вызывая какую-либо функцию.
Например, пусть у нас есть класс для транзакций trans_t. Для удобного использования, он должен иметь явные метоы commit - могущий выкинуть исключение и rollback - не выкидывающий.
В деструкторе транзакция должна проверять была ли она завершена, и если нет, вызывать rollback.

Так же и file_t - должен иметь функцию flush - сбрасывающую буфера на диск и могущую выкинуть исключение и функцию close закрывающую файл без исключений. В деструкторе вызывается именно close если файл всё ещё открыт.

Ну и RAII (http://ru.wikipedia.org/wiki/RAII) - всего лишь удобная аббревиатура ссылающаяся на совершенно конкретный приём/шаблон программирования.
Ничего особо выдающегося или гениального в ней нет - всего лишь систематизация, как и написал BRE