Привет!


Вчера задавал вопрос про поддержку execption в Qt. Мне ответили, что Qt не поддерживает их (вместо этого ф-ции возв. true, false или код ошибки).

С чем это связано, может из-за того, что QT кроссплатформенная и исключения не поддерживаются в какой-то ОС?

Я собираюсь делать кросплатформенную прогу, вот и думаю юзать мне exception (это же стандарт с++) или обойтиись без них как в qt?

*cобирать приложение буду под MacOS, Windows, Linux.

спасибо!

Гугление даёт причину:



Если ты собираешься переносить свою программу на те экзотические компиляторы, которые не поддерживают исключений или использовать Qt в своём коде, то от исключений, наверное, придётся отказаться. Впрочем, про насчёт совместного использования Qt и исключений я не уверен. Желательно спросить/поискать мнения людей, которые пробовали такую связку.

Свои исключения генерировать естественно ничто не мешает. Разве что здравый смысл.

В документации, не раз говориться про НЕ использование в Qt исключений. Но сам, своими глазами видел их в коде.
Так что, думаю что все же они имеют право испускаться.

откуда такое отношение?
нравится писать спагетти код, с проверкой кодов возврата?

Добавлено через 27 секунд

в коде Qt?  

Да) щас покажу

Добавлено через 8 минут и 1 секунду
К примеру:


и дальше..

вот макросы:



По умолчанию компилируется с -UQT_NO_EXCEPTIONS

qt-4.6.0-opensource-msvc2008

>откуда такое отношение?

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

Коды возвратов != спагетти. Месиво и из эксепшинов ничто не мешает нагородить. И так кстати часто случается: ни раз видел тысячи catch на все случаи жизни.

И вообще это крайне холиворная тема, ну ее нафиг.

они исключительные ситуации

я бы сказал, что главный повод их использовать - это то, что исключение нельзя проигнорировать, я уже тут писал об этом - http://forum.vingrad.ru/forum/topic-216818/0.html#


если пишешь на Haskell-e, и используешь монаду Maybe, то да, в остальных случаях - получается спагетти код, 
если операция1 то
    если операция2 то
        если ...
    иначе обработка ошибки
иначе обработка ошибки
есть 2 альтернативы, нечто похожее на монаду Maybe из хаскеля, либо исключения, в С++ доступен только второй вариант


ну что за манеры? 

>они исключительные ситуации

Никто и не спорит. Другой вопрос - как их обрабатывать.

>я бы сказал, что главный повод их использовать - это то, что исключение нельзя проигнорировать

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

>есть 2 альтернативы

Альтернатив как оказалось несколько больше. И не удивлюсь, что есть еще. Навскидку.

3.


4. Одинаковые "обработки" выносятся в отдельный предсмертный блок функции, вызванный через goto. Сейчас в меня наверное полетит что-нибудь вроде "кто ж использует гоуту в двадцать первом то веке? деревня!". На деле это случается редко (на моей практике), но как по мне, так ничего плохого в этом нет: код легко читается, нет никаких спагетти и самое главное (шучу) - ни единого експшена.

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


в С++ - обязательно  

это вариации
вообще, есть один критерий, все эти вариации на тему спагетти кода - о том, как смешать обработку ошибок со всем остальным кодом, а исключения позволяют разделить нормальный код и код обработки ошибок. Если использовать не if а goto, или return, сути это не изменит, код помимо своих функций занимается обработкой нештатных ситуаций, это усложняет код и как следствие - уменьшает его надежность


не надо путать postmortal и нормальную обработку ошибок, есть приложения, для которых недопустима потеря данных, есть приложения для которых недопустим простой, представь, что в каком-нибудь авиадиспетчерском центре упадет приложение, оно конечно перезпуститься, но во время простоя может случиться удивительное 

djamshud, ты видимо не до конца понимаешь смысл исключений. Они генерируются тогда, когда данный участок программы понятия не имеет что делать с возникшей ситуацией. Это случается, допустим, раз в час. А результатом будет сообщение, что пользователь выполнил недопустимую операцию и будет уничтожен...     Другими словами, исключение - это что-то внештатное, что теоретически может случиться, но маловероятно, и совершенно неважно, сколько времени будет разворачиваться стек - 0.1 мс или 100 мс. Так как в случае ручной обработки все будет тоже самое, только придется код анализа состояний писать самостоятельно.

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

>а я придерживаюсь мнения, что разработчик библиотек, вправе забрать у программиста возможность игнорировать ошибки

Да. А автомобиль обязан пристегивать свое содержимое ремнями безопасности и ограничивать силу нажатия на педаль.

Так получается, что разработчик вспомогательного средства решает, что делать его (средства) пользователю. Странно оно как-то, не находите?

>в С++ - обязательно

Нет. Операционка не станет вызывать никаких деструкторов и стеки разматывать тоже не будет. Грохнет, освободит ресурсы и как ни в чем ни бывало.

>это вариации

Да, и они демонстрируют отсутствие в коде всякого спагетти. Или давайте в таком случае называть макаронами любые ветвления. 

>код помимо своих функций занимается обработкой нештатных ситуаций

Что во-первых вполне нормально, а во-вторых ничто не мешает локализовать обработку (именно локальную) в конце функции, оставив "наверху" основной функционал кода. И что мы имеем? Произошел маленький кердык - перешли в конец функции и закрыли сокет, вернули единицу, на верхнем уровне, приняли решение, что же делать дальше. Сравните: кердык - эксепшн - поиск, где же он перехватывается, закрытие сокета и принятие решение о дальнейших действих. Т.е. добросовестно смешиваем локальное и внешнее обработки ошибки. Очень удобно! Особенно поддерживать это чудо-юдо.

>во время простоя может случиться удивительное

И как же исключение спасет пассажиров и членов экипажа? Проморгали код возврата или проухали исключение - результат один - катастрофа. Потому что даже поймав исключение где-нибудь в main (последний рубеж обороны), хрен что толкового с ним сделаешь (толковое можно было сделать раньше), самолет уже в штопоре.

Добавлено через 3 минуты и 26 секунд
>djamshud, ты видимо не до конца понимаешь смысл исключений.

Может быть именно поэтому я не понял из вашего сообщения, в чем профит уничтожения пользователя именно через эксепшн.

Добавлено через 8 минут и 10 секунд
PS. Не нужно мне не правильно понимать, я не за отмену исключений и не за аннигиляцию программистов, которые "правильно" их используют (почему не использую их я и как с этим живу - писал). Я против их тотального применения на каждый чих. Часто чих объясняют именно исключительностью, что таковой в 99% случаев не является.

самый простой пример, пользователь создает объект
Foo* foo = new Foo();
но во время создания возникает ошибка, тут дело даже не в том, что нельзя вернуть из конструктора код ошибки, проблема в том, что если пользователь проигнорирует ошибку, он будет пользоваться невалидным объектом, и при первом-же его использовании произойдет следующая ошибка, но причину этой ошибки найти будет сложнее

а я думал, что мы договорились о том, что наше, управляющее самолетом приложение не пишет в лог "ААААААААААААА!!!!!!!!" и отваливается, а пытается продолжить работу, корректно
кстати, в некоторых случаях после перезапуска все не будет как ни в чем не бывало, если приложение должно обеспечивать целостность каких-либо данных на жестком диске и при этом оно упадет в середине какой-нибудь операции, изменяющей эти данные, то в следующий раз оно может и не запуститься  

они демонстрируют множество точек возврата из одной ф-ии, плохой стиль
в любом случае, без исключений, control flow будет намного сложнее


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

ну так раньше и нужно его обрабатывать

А может в "С/С++ Общие вопросы" ? ;)

>Foo* foo = new Foo();

Указатель все равно будет корректным. Память успешно выделена. Стало плохо прям в конструкторе? Не помню, чтоб хоть раз такое сделал, но можно обойтись каким-нибудь внутренним флагом errno и убить недосозданный объект. В любом случае имхо обсуждению не подлежит из-за кривизны самой идеи - подыхать неродившись.

>а я думал, что мы договорились о том, что наше, управляющее самолетом приложение не пишет в лог "ААААААААААААА!!!!!!!!" и отваливается, а пытается продолжить работу, корректно

Ну так там мы про самолеты и не говорили. Данные могут быть повреждены, да, тут спорить не о чем. И опять исключение никак не спасет данные.

>они демонстрируют множество точек возврата из одной ф-ии, плохой стиль

Кому плохой, а кому - нет. Это чистой воды субъективизм. Кроме того с goto место возврата одно.



Про кердыки посмеялся, спасибо.

Произошел маленький кердык с сокетом. Сообщили верхнему уровню. Он не принял решения? Почему? Ну ладно, это мы переживем. Но почему же мы, зная, что кердык произошел где-то ниже, говорим верху-приверху, что кердык у нас? Ну так на это есть разные коды возвратов. Целый инт минус один. И повторю, ИМХО не совсем здорово, когда ошибки обрабатываются через несколько уровней вызовов. Но, как я пояснил, и код возврата можно (и нужно, раз уж на то пошло)
 пересылать правильно.

>ну так раньше и нужно его обрабатывать 

Ну так верно. И не важно, исключением, кодом возврата или магией.