Russian Qt Forum
Март 29, 2024, 01:47 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2] 3   Вниз
  Печать  
Автор Тема: как правильно прервать конструктор класса?  (Прочитано 20357 раз)
kuzulis
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2812


Просмотр профиля
« Ответ #15 : Апрель 07, 2010, 07:43 »

Цитировать
А унаследовался от такого объекта - проверки валидности лезут в новые/перекрытые методы. В общем все это начинает неприятно быстро расползаться.
дадада.. + пицот
Записан

ArchLinux x86_64 / Win10 64 bit
SABROG
Гость
« Ответ #16 : Апрель 07, 2010, 09:32 »

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

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

Цитировать
исключения входят в стандарт языка
RTTI тоже входит, только его особо не жалуют. Много чего входит, только оно еще не реализовано или не везде.
« Последнее редактирование: Апрель 07, 2010, 09:35 от SABROG » Записан
SASA
Гость
« Ответ #17 : Апрель 07, 2010, 11:26 »

А есть ли в qt конструкторы, которые выбрасывают исключения?
Записан
SABROG
Гость
« Ответ #18 : Апрель 07, 2010, 14:23 »

А есть ли в 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;
   }
}
 
Записан
niXman
Гость
« Ответ #19 : Апрель 07, 2010, 14:27 »

Цитировать
Сомневаюсь, что большинство программистов используют try{} catch() везде где только возможно или даже проверяют коды возвратов где это возможно.
ужос Шокированный
вам бы на Си писать. или на чем-то подобном.

Цитировать
Поэтому работа с невалидным объектом обычное дело.
снова ужос Шокированный

подавляющее большинство программеров, не используют исключения, т.к. не знают/не понимают в чем их плюсы.
а коды ошибок..что тут понимать, оверхедим/хардкодим кучу проверок условий, 20 ифов, или свичь на все случаи жизни Смеющийся
ппц одним словом.
да, Qt приучает так кодить Подмигивающий
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #20 : Апрель 07, 2010, 16:21 »

"Большинство программистов" где? На этом форуме? На Qt? Или "в мировом масштабе"?  Улыбающийся Я гораздо чаще сталкивался с другой крайностью - неумеренное (на мой взгляд) испускание exception, даже там где спокойно можно обойтись кодом возврата. Все хорошо в меру и спорить не о чем. Сам пробовал оба пути, мое мнение пусть не всегда, но частенько с exception получается значительно короче и чище.
Записан
niXman
Гость
« Ответ #21 : Апрель 07, 2010, 16:40 »

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

Цитировать
Я гораздо чаще сталкивался с другой крайностью - неумеренное (на мой взгляд) испускание exception
try{} catch() - предназначены для обработки !исключительных ситуаций!. да, иногда встречается перебор, но в процентном соотношении, это около 10 процентов от кол-ва оверхеда при проверке результатов/флагов.
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #22 : Апрель 08, 2010, 20:01 »

niXman
особенно "исключительная" ситуация - файл занят другой программой при открытии его на чтение (c#). Любите эксепшны...
Записан
Tonal
Гость
« Ответ #23 : Апрель 16, 2010, 08:13 »

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

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

Поэтому, в хорошем коде довольно мало мест, где встречается конструкция try...catch.
Их может быть в разы, а то и на порядок меньше чем мест, где бы пришлось проверять флаги завершения и валидности. Улыбающийся
Код получается компактнее и нагляднее.
Правда с исключениями обязательно нужно использовать технику RAII иначе уродства типа показанного SABROG-ом и более навороченных не избежать.
Записан
Barmaglodd
Гость
« Ответ #24 : Апрель 16, 2010, 09:34 »

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

PS: Я не против исключений, я за разумный подход в выборе метода сообщения об ошибках Улыбающийся
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #25 : Апрель 16, 2010, 11:45 »

то ли я не понял RAII то ли я тупой:)
а) какая связь между количеством исключений и тем, как создаются/освобождаются ресурсы.
б) смысл RAII - в том чтобы, о боже, освобождать ресурс в деструторе? А кто-то так не делает? по-моему знание "паттернов" только мешает жить, они все такие гениальные...
Записан
BRE
Гость
« Ответ #26 : Апрель 16, 2010, 11:54 »

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

моему знание "паттернов" только мешает жить, они все такие гениальные...
В паттернах ничего гениального нет, при программировании ты рано или позно придешь к этим приемам сам.
Их достоинство в систематизации этих приемов.
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #27 : Апрель 16, 2010, 12:21 »

Одно из свойств RAII это как раз гарантированное освобождение ресурсов при выходе из зоны видимости. Поэтому, если происходит исключение ресурсы гарантированно освободятся.
я бы сказал это единственное его свойство:)
в том-то и проблема что я гляжу на каждый новый паттерн и удивляюсь "а чо тут такого гениального"
Записан
Barmaglodd
Гость
« Ответ #28 : Апрель 16, 2010, 12:33 »

Никто никому не гарантирует освобождение ресурсов, даже вызов деструктора не всегда гарантируется. Подмигивающий
Записан
BRE
Гость
« Ответ #29 : Апрель 16, 2010, 12:42 »

Никто никому не гарантирует освобождение ресурсов, даже вызов деструктора не всегда гарантируется. Подмигивающий
Скажем так, гарантирует вызов деструктора, а вот с освобождением ресурса... тут от ресурса зависит.  Улыбающийся
Записан
Страниц: 1 [2] 3   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.181 секунд. Запросов: 23.