LINUX.ORG.RU

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

 


2

4

Волею случая сейчас делаю один проект на Qt, после Java хочется жирненько обмазать метод исключениями, а тут опаньки и такое вот написано, почему так?

http://qt-project.org/wiki/Coding-Conventions

Перемещено mono из talks

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

zorg ★★
()

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

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

Adonai ★★★
()

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

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

E ★★★
()

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.

dogbert ★★★★★
()

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

ranka-lee
()

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

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

Camel ★★★★★
()
Ответ на: комментарий от Gvidon

Забить код

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

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

Camel ★★★★★
()
Ответ на: комментарий от Pavval

IMHO сложнее.

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

m0rph ★★★★★
()
Последнее исправление: m0rph (всего исправлений: 1)
Ответ на: комментарий от ranka-lee

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Gvidon ★★★★
()
Последнее исправление: Gvidon (всего исправлений: 1)
Ответ на: комментарий от m0rph

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

Pavval ★★★★★
()

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

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

batbko
()

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

KblCb ★★★★★
()

почему так?

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от Pavval

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

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

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от ddos3

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

ranka-lee
()
Последнее исправление: ranka-lee (всего исправлений: 2)
Ответ на: комментарий от ranka-lee

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

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

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

это как?

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

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

ranka-lee
()
Ответ на: Забить код от Camel

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

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

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

Pavval ★★★★★
()
Ответ на: комментарий от ranka-lee

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

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

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

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

ddos3
()
Ответ на: комментарий от ranka-lee

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

Begemoth ★★★★★
()
Последнее исправление: Begemoth (всего исправлений: 2)
Ответ на: комментарий от Pavval

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

ddos3
()
Ответ на: комментарий от Pavval

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

Reset ★★★★★
()
Ответ на: комментарий от Pavval

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

Reset ★★★★★
()
Ответ на: комментарий от Begemoth

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

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

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

Pavval ★★★★★
()
Ответ на: комментарий от ddos3

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

Pavval ★★★★★
()
Ответ на: комментарий от Reset

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

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

Reset ★★★★★
()
Ответ на: комментарий от Gvidon

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

nanoolinux ★★★★
()
Ответ на: комментарий от Pavval

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

Begemoth ★★★★★
()
Ответ на: комментарий от Reset

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

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

Pavval ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

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

nanoolinux ★★★★
()
Ответ на: комментарий от anonymous

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

g0t0
()
Ответ на: комментарий от Begemoth

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

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

Begemoth ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.