Ещё бы оператор if запретили.

http://qt-project.org/forums/viewthread/2343
Там в комментах чувак отметился.

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

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

Это тянется ещё с тех пор, когда исключения отжирали память и размер бинарника, даже если их не используешь. А добавить исключения в Qt сейчас - это переписать половину кода и пересмотреть архитектуру. Может, в Qt6 введут, кто знает.

Плюс до сих пор оставшийся косяк с некорректным освобождением в деструкторах/конструкторах. Qt, в отличие от STL, стрельбу в ногу не приветствует.

Exceptions have advantages and disadvantages:

plus:

Easy exit of the application / function
can contain any information (text, code etc, also combined)

minus:

slower execution (exceptions transportation code must be added and is added to all functions)
more binary code (+ ~10% – 15%)
If you have exceptiosn and don’t use smart pointers, cleanup is often buggy —> heap objects stay where they are etc.

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

Успокоение внимания

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

И для этого придумали проверяемые исключения.

Ты так говоришь, будто забить болт на код возврата сильно сложнее.

Забить код

Ты так говоришь, будто забить болт на код возврата сильно сложнее.

Вы, конечно, правы. Хорошему программисту исключения не помеха, плохому и код возврата не поможет.

IMHO сложнее.

IMHO сложнее.

Чем сложнее? Исключение обрабатывать придется в любом случае, а о коде возврата некоторые задумываются только в случае, когда «почему-то не работает».

Какой косяк? Неосилятор?

Проблемы только у неосиляторов. Объект в C++ при исключении в конструкторе не будет создан, никаких недоинициализированных объектов

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

Объект в C++ при исключении в конструкторе не будет создан

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

Сложнее тем, что вызывая ранее неведомую ф-цию, ты видишь ее сигнатуру и видишь код возврата. А вот все возможные высыраемые исключения ты не видишь.

Это соглашения для кодеров Qt, а не кодеров на Qt. Видимо исключения есть не везде, где есть Qt.

Интересный факт - у гугла примерно такоже чек лист для плюсового кода :)

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

почему так?

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

Сложнее тем, что вызывая ранее неведомую ф-цию, ты видишь ее сигнатуру и видишь код возврата.

Видишь и? Обычно, чтобы правильно его интерпретировать всё равно надо в документацию смотреть. Это вообще полезно делать - зачастую надо знать пред/пост-условия функции и всё такое. В таком случае, и про исключения не проблема посмотреть. Тем более, что у Qt отличная документация.

Имхо, тут скорее в другом дело. У таких вещей типа Ят коды возврата меньше ограничивают. В смысле, при желании можно в своём коде проверить результат и дальше кинуть исключение, если уж мы решили их использовать. Обратная ситуация когда либа исключениями кидается, а в остальном коде решили без них обходиться выглядит коряво.

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

Если используешь RAII, то так и будет. А если быдлокодишь, то ССЗБ.

В C++ лучше быть неосилятором.

У RAII есть маленькая проблема - синхронность. Ресурсы часто требуют относительно длительного времени для инициализации, вроде чтения файла. Вот что ты будешь делать с исключением которое вылетело в каком нибудь потоке из thread pool? А без асинхронности нельзя, синхронное говно это главный источник тормозов.

Проблема с возможностью утечек памяти

А кто сейчас использует голые указатели для владеющих указателей? Только ССЗБ или поддерживающие древний код.

недоинициализироанные объекты

это как?

Их уже раздумали, до nothrow.

Ага. Серьёзное использование смартпоинтеров это признак говна в коде, когда никто не знает что именно в нём происходит. Годится только чтобы не писать delete в деструкторе или на выходе из блока.

Хорошему программисту исключения не помеха

Пропущенное исключение все-таки лучше непроверенного кода возврата. В первом случае программа грохнется сразу, а в втором будет делать что-то неопределенное время пока не грохнется.

синхронное говно это главный источник тормозов

А асинхронное - багов. Жизнь - боль.

Пропущенное исключение все-таки лучше непроверенного кода возврата. В первом случае программа грохнется сразу, а в втором будет делать что-то неопределенное время пока не грохнется.

Кому лучше? Ты не поверишь, но есть софт, которому крайне не рекомендуется падать.

синхронное говно это главный источник тормозов.

А пруфы будут?

Вот что ты будешь делать с исключением которое вылетело в каком нибудь потоке из thread pool

А что ты будешь делать с errno в том же потоке в том же месте?

В точности наоборот, смарт-поинтер это не только автоматическое управления памятью, это документация, указывающая на семантику владения. Фактически, способ писать код безопасный по отношению к исключениям - это использовать RAII повсеместно (лапшу из try-catch трудно назвать альтернативой). Причем это не зависит от языка, это могут быть объекты, управляющие ресурсами, в C++, try-with-resources в Java, using в C#, use в F#.

есть софт, которому крайне не рекомендуется падать

Лучше похерить данные пользователя случайным образом?

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

Проверка кодов возврата приводит к созданию лапшеобразного плохочитабельного кода ala Си. Исключения проще и понятней.

Эту проблему решают внешними watchdog'ами. Если логика программы нарушена внутри программы, то изнутри ты восстановиться корректно не сможешь.

Для решения этой проблемы изобрели exception_ptr.

Лучше похерить данные пользователя случайным образом?

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

Тебе маленький пример: Microsoft Word. Часто было такое, что он отрабатывал неправильно и аццки херил форматирование? Это всё его баги. Только по ним он не вылетал, а просто «херил данные». Но у пользователя всегда есть запас матерных слов и Ctrl+Z в придачу, потому проблема далеко не стоит того, чтобы вылетать.

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

Если логика программы нарушена внутри программы, то изнутри ты восстановиться корректно не сможешь.

Если ты _пишешь_ программу с учетом подобных вещей (сложно, но можно), то _сможешь_ в 99.9% случаев, где ты сейчас думаешь просто валить программу. Пруфов не будет, ибо NDA.

Правильно не допускать подобных проблем, а не обвешиваться простынями костылей и загромождать код. Программа упала, увидели stacktrace в логе watchdog'а, пофиксили, выкатили новую версию. Кто делает иначе того надо вешать за яйца и расстреливать.

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

Сейчас ты несколько не о том пишешь, и я, и Reset говорили о случаях, которые не попадают в те, что ты учёл при написании программы.

Программа упала, увидели stacktrace в логе watchdog'а, пофиксили, выкатили новую версию. Кто делает иначе того надо вешать за яйца и расстреливать.

Какой ты идеалист, аж лол. Оффтоп конечно, но всё таки: программа упала, пользователь матернулся и перезапустил. И так год. А потом просто решается не покупать эту программу, т.к. она глючная.

в бусте решили

Ничего они не решили. Просто к ним пришла зелёная фея и подсказала решение. Если вы понимаете о чём я.

Ты бы плохому-то людей не учил. Этот форум ведь и дети тоже читают.

Которое активно срёт в куче?

А ТО!

Сейчас ты несколько не о том пишешь, и я, и Reset говорили о случаях, которые не попадают в те, что ты учёл при написании программы.

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

Оффтоп конечно, но всё таки: программа не упала, пользователь не матернулся, он через неделю заметил, что его данные за прошлый год куда-то делись или изменились до неузнаваемости.