С++ EH и логика на исключениях

[metaclass]

Хорошо ли в C++ программе делать логику на исключениях?
Я ща втыкаю в одну опенсорсную СУБД в продакшене отладчиком и вижу что там на каждый запрос валится стопицот крестиковых исключений, и не понимаю, это нормально или нет.

Comments

[cross-join.livejournal.com]

Для систем класса СУБД ненормально, лишние затраты, время и т.д.
Для ООП в целом - стандартный подход, исключение - это способ послать сообщение.
Отсюда вывод, для написания СУБД надо уметь оба подхода.

[vit-r.livejournal.com]

"Старнартный подход" - это потому, что "у нас в коллективе такие идиоты, что проверить возвращаемое значение функции не могут"

Сообщения - это сообщения.

[cross-join.livejournal.com]

Исключение тоже возвращает значение, только в виде объекта.

[maxdz.livejournal.com]

Исключение делает (и добавляет в код) намного больше, чем просто отсылка сообщения.

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

[cross-join.livejournal.com]

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

[maxdz.livejournal.com]

>накладные расходы на реализацию средой и компилятором исключений сильно преувеличены

~ +10-20% роста размера кода и снижения быстродействия, в сравнении даже с C++ без исключений (не говоря уж о C), для средних приложений, с активным использованием исключений лишь для обработки ошибок.

А если пользоваться исключeниями для обычных нотификаций - за такое надо давать канделябром.

[cross-join.livejournal.com]

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

[maxdz.livejournal.com]

"стандартный способ сообщений о любых внештатных ситуациях"

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

Исключения вызывают очень много проблем:
- для каждой функции, делающей throw, компилятор делает "обёртку" с информацией, нужной для правильного разворачивания стэка/вызова деструкторов для объектов на стэке
- функции со throw, как правило не могут вбыть соптимизированы (например, сделаны inline)
- c++ сложный язык и компилятор намного сложнее c-шного. Соответственно, c++ компиляторы реализованы для намного меньшего количества платформ, чем c, кроме того изобилируют ошибками, бывают ошибки и в кодогенерации, связанной с исключениями

В общем, исключения сами по себе, не cамый удачный инструмент при написании СУБД. А если уж кидать исключения, просто для информирования без каких-либо ошибок...

[cross-join.livejournal.com]

Использовать исключения для штатных ситуаций невозможно по одной простой причине: они прерывают выполнение программы.
То что валится автору, скорее всего, исключения, посылаемые разными evalator выражений и значений, разработчики не предусмотрели обычных функций типа TryEvaluate c возвратом статуса.

[vit-r.livejournal.com]

Основная проблема исключений - они прячут логику управления программой.

[maxdz.livejournal.com]

Это проблема не исключений, а C++ :)

[vit-r.livejournal.com]

Ничего не мешает из функции вернуть объект.

Исключение - это исключение. Отказ ресурса или ошибочные данные - это штатная ситуация в программе.

[cross-join.livejournal.com]

Мешает необходимость явного контракта "кто освобождает возвращаемый объект", распространяющегося на все функции в программе. В программе на миллион строк отслеживать ошибки такого рода затруднительно.
Да и незачем перекладывать это на программиста без особых причин.
В процедурном стиле для возвратов используются структуры (записи), а не объекты.

[vit-r.livejournal.com]

Работа с памятью - это на порядок более простая проблема, чем алгоритмы и правильная обработка.

[cross-join.livejournal.com]

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