Наследование от std::exception

Приветствую всех. Создаю библиотеку классов и в некоторых (исключительных) случаях планирую кидать исключения. Скажите, имеет ли смысл класс исключения наследовать от std::exception? Если имеет, то укажите, пожалуйста, причины.

0

Сообщение от d7d1cd Скажите, имеет ли смысл класс исключения наследовать от std::exception?

в твоём случае - нет, не имеет.
потому что тебе вообще не нужны собственные классы эксепшенов.

используй стандартные: std::logic_error, std::runtime_error, etc

0

Сообщение от hoggy потому что тебе вообще не нужны собственные классы эксепшенов. используй стандартные

Ну как то, вроде, делается стильная, модная, молодежная библиотека со всеми своими классами (в том числе строками и числами), а исключения пользователю приказать ловить стандартно? Не хорошо... Многие библиотеки классов (VCL, FMX, например) не используют стандартные классы исключений. Свои имеют. Чем мы хуже?
Кроме этого, мало мне в качестве информации об исключении одного текстового поля.

0

Сообщение от d7d1cd Ну как то, вроде, делается стильная, модная, молодежная библиотека со всеми своими классами (в том числе строками и числами), а исключения пользователю приказать ловить стандартно? Не хорошо... Многие библиотеки классов (VCL, FMX, например) не используют стандартные классы исключений. Свои имеют. Чем мы хуже? Кроме этого, мало мне в качестве информации об исключении одного текстового поля.

Унаследуйся, хуже точно не будет. Тогда хотя бы твоё исключение можно будет отловить по std::exception

0

Сообщение от d7d1cd а исключения пользователю приказать ловить стандартно? Не хорошо...

всегда стандартно.
даже если это кастомные эксепшены.
их всё равно всегда ловят стандартным образом:

если эксепшен не отнаследован от std::exception,
это такой красноречивый признак делитанта,
который пишет ненадежный код.

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

об этом пара слов поподробнее:

что не так с этим кодом?
для того что бы бросить эксепшен, его нужно сначала сконструировать.
при конструировании используется выражение std::string(file),
которое в свою очередь тоже может бросить исключение.
и тогда вместо рантайма полетит бадаллок.
таким образом, вместо вменяемой диагностики,
можно неиллюзорно схлопотать нежданчик,
который замаскирует исходную проблему.

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

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

Сообщение от d7d1cd (VCL, FMX, например)

нашел на кого ровняться.

тупиковая ветвь в эволюции
я вот даже не знаю, что у них там под капотом.

второе - даже не гуглится.

2

hoggy, я читал твои сообщения в других темах, поэтому понимаю, что тягаться с тобой в знании С++ себе дороже . Спасибо за развернутый ответ.
То есть, даже если я создам свой класс исключения, унаследовавшись от std::exception, передаваемые в исключении значения в программе должны быть константами?

Сообщение от hoggy тупиковая ветвь в эволюции. я вот даже не знаю, что у них там под капотом.

Почему тупиковая? Embarcadero поддерживает эту библиотеку.
Кстати, их базовый класс исключений Exception не унаследован от std::exception.

Сообщение от hoggy второе - даже не гуглится.

https://ru.wikipedia.org/wiki/FireMonkey

0

0

Сообщение от d7d1cd Почему тупиковая?

Сообщение от d7d1cd Кстати, их базовый класс исключений Exception не унаследован от std::exception.

Сами спросили сами и ответили?)
Уже лучше библиотеку писать вообще без исключений, что кстати и часто делают.

Сообщение от d7d1cd Embarcadero поддерживает эту библиотеку.

Ну любят люди труп пинать и что дальше?

0

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

0

Сообщение от Алексей1153 не знаю, как другим, а лично меня раздражают библиотеки/функции, которые швыряются исключениями. На кой они мне? Только код загромождать. Мне вполне достаточно возврата false/код ошибки /текст ошибки

Я не говорю, что надо пихать исключения везде и всюду. Но есть ситуации, когда без исключения не вижу выхода. Пример. Есть класс строки. Запрашивается индекс несуществующего элемента через оператор []. Как обойтись без исключения?

0

Сообщение от d7d1cd Как обойтись без исключения?

Бить по рукам.
И того кто хотел сделать чтобы оператор [] исключения бросал - тоже.

1

Сообщение от d7d1cd Запрашивается индекс несуществующего элемента

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

0

Сообщение от d7d1cd Я не говорю, что надо пихать исключения везде и всюду. Но есть ситуации, когда без исключения не вижу выхода. Пример. Есть класс строки. Запрашивается индекс несуществующего элемента через оператор []. Как обойтись без исключения?

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

ты вообще понимаешь, зачем нужны исключения?

0

Сообщение от hoggy ты вообще понимаешь, зачем нужны исключения?

Теперь уже не знаю... Расскажите.

И никто из 3-х человек не сказал что делать, если возникает ситуация в приведенном выше примере.

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

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

Это какой отладчик показывает выход за границы массива?

0

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

0

Сообщение от d7d1cd Расскажите.

Ну, вот допустим я как обычный белый человек имею массив чисел - 1, 2, 3, 4, 5, 6, 7.
У меня есть какой-то контейнер в котором я храню эти значения. И вот мне надо сделать какие-то вычисления (сложить, умножить там и тд) над данными числами, я как хороший программист вынесу это в функцию:
В ней мне по любому надо получить доступ к нужному мне элементу и что-то посчитать. В какой-то момент я выхожу за границы массива (что есть UB) и падаю, с огромными глазами я смотрю почему же я упал в terminate, а оказалось, что кто-то умудрился бросать исключения из оператора []. Пофиксив проблему с выходом за границы массива, я не могу оставить мой код прежним..
Мне надо все обращения к оператору [] оборачивать в try-catch блок и я надеюсь его исключения отнаследованы от std::exception иначе бить уже можно выше рук. И мой пример уже выглядит так:
Или убирать noexcept спецификатор.
Любой из этих вариантов плохой и несет за собой огромный оверхед, и я просто с пустого места лишаюсь части оптимизаций, а я ведь просто хотел получить элемент из массива...

Добавлено через 2 минуты

Сообщение от Алексей1153 почти всегда вызывает краш

Не всегда, т.к. выход за пределы это UB. И если и вызывает, то это скорее работа ASAN'a.

0

Сообщение от d7d1cd Что тут должно произойти без исключения?

assert должен сработать. Ибо это не исключительная ситуация, а просто ошибка программиста.

1

Azazel-San, так зачем оборачивать в try-catch? Ошибка выхода за пределы массива найдена же. По сути, исключение в операторе [] для этого и бросалось: чтобы указать, что где-то происходит выход за пределы массива...
Но теперь DrOffset указал, что это не исключительная ситуация, а ошибка программиста и показал как надо поступать в таком случае. Спасибо!
Но по исключениям все равно вопрос. Например, метод at std::vector при выходе бросает исключение. Но ведь это не исключительная ситуация, а ошибка! Почему тогда бросается исключение?

0

Сообщение от d7d1cd метод at std::vector при выходе бросает исключение.

Сообщение от d7d1cd Но ведь это не исключительная ситуация, а ошибка! Почему тогда бросается исключение?

Потому что так захотел разработчик библиотеки. В данном случае для метода at выход за пределы диапазона рассматривается как исключительная ситуация.

Предчувствуя у вас когнитивный диссонанс сразу скажу, что нет особого смысла выяснять эти вещи в отрыве от проекта. Возможно мы можем найти такую область, где выход за пределы вектора можно рассматривать как исключительную ситуацию, и тогда нам понадобится vector::at вместо vector::operator[]. Однако по моему опыту я применял vector::at ровно 0 (ноль) раз. Т.е. в моей практике не было достаточно весомых случаев для применения этого кейса.

Добавлено через 2 минуты

Сообщение от d7d1cd Ошибка выхода за пределы массива найдена же. По сути, исключение в операторе [] для этого и бросалось: чтобы указать, что где-то происходит выход за пределы массива...

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

0

Сообщение от d7d1cd Azazel-San, так зачем оборачивать в try-catch?

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

Сообщение от d7d1cd Но теперь DrOffset указал, что это не исключительная ситуация, а ошибка программиста и показал как надо поступать в таком случае.

assert - это хорошо, но на самом деле он не защищает от всех видов ошибок программиста и/или правильности поведения логики его кода. Тем более не факт, что этот assert будет там где вы его ожидаете, поэтому для предотвращения своих ошибок я бы воспользовался ЮТ, которые дадут больше гарантий.
Это скорее отличный инструмент который в некоторых моментах и расставленный в нужных местах может сохранить много времени, но я бы не стал только на него полагаться или злоупотреблять им.

Сообщение от d7d1cd Но ведь это не исключительная ситуация, а ошибка!

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

Сообщение от d7d1cd Почему тогда бросается исключение?

Вдохновлялись Джавой? Вообще интересно для чего был придуман этот метод и какой функционал в него вкладывали. Был ли он изначально или его позже добавили через пропозал? Если кто и знает, то только DrOffset

0