Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение?
Ничего
Пишу капсом комментарий / указываю в доках
Использую exception specification
Указываю в названии функции
У меня все функции бросают исключения, так что никак
Второе использую итак, но считаю, что этого недостаточно (найдётся кто-нибудь, кто не прочтёт / не дочитает до конца комментарий / доки).
exception specification не хочу использовать из-за возможности того, что человек, которому придётся поддерживать данный код, забудет посмотреть, какие типы исключений она может бросать, и вызовет std::unexpected.
Если Вы выбрали последний вариант, то как Вы указываете, какие именно типы может выбрасывать данная функция?
В общем, хотелось бы услышать Ваши мнения по этому поводу.
Re: Как показать, что функция может бросать исключение
если предполагается что есть смысл делать отдельный catch для этого исключения, пишу об этом в комментарии, например
/// \throws bad_some_cast
A& some_cast(B& b);
тогда юзер будет знать что он может написать catch(bad_some_cast&)
если же исключение не предусматривает отдельный catch, то и писать о нем не надо,
struct fatal_error : std::runtime_error {...};
его будут ловить в catch(std::exception&)
In Zen We Trust
Re[2]: Как показать, что функция может бросать исключение
A>если же исключение не предусматривает отдельный catch, то и писать о нем не надо, A>struct fatal_error : std::runtime_error {...}; A>его будут ловить в catch(std::exception&)
А где этот самый catch-блок будет находиться? Представим, что клиент не предполагал, что данная функция бросает какое-либо исключение и не ловил его при вызове, в результате чего оно долетело до main, где всё-таки был написан обработчик, или завершило программу. Или Вы вокруг каждой функции пишите catch-блоки?
Re: Как показать, что функция может бросать исключение
Здравствуйте, Nikita.Trophimov, Вы писали:
NT>Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение?
NT>
NT>Ничего NT>Пишу капсом комментарий / указываю в доках NT>Использую exception specification NT>Указываю в названии функции NT>У меня все функции бросают исключения, так что никак NT>
NT>Второе использую итак, но считаю, что этого недостаточно (найдётся кто-нибудь, кто не прочтёт / не дочитает до конца комментарий / доки). NT>exception specification не хочу использовать из-за возможности того, что человек, которому придётся поддерживать данный код, забудет посмотреть, какие типы исключений она может бросать, и вызовет std::unexpected.
NT>Если Вы выбрали последний вариант, то как Вы указываете, какие именно типы может выбрасывать данная функция? NT>В общем, хотелось бы услышать Ваши мнения по этому поводу.
Очень интересная тема, с удовольствием почитаю то, что здесь напишут. От себя пока напишу только то, что суровая действительность давно уже научила не верить ни комментариям, ни документации. Верить можно только коду, пропущенному через компилятор.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[3]: Как показать, что функция может бросать исключение
On 06.03.2013 20:16, Nikita.Trophimov wrote:
> Представим, что клиент не > предполагал,
Представим, что клиент вообще не умеет программирвоать? Конструктивно?
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Как показать, что функция может бросать исключение
Здравствуйте, Nikita.Trophimov, Вы писали:
A>>если же исключение не предусматривает отдельный catch, то и писать о нем не надо, A>>struct fatal_error : std::runtime_error {...}; A>>его будут ловить в catch(std::exception&)
NT>А где этот самый catch-блок будет находиться? Представим, что клиент не предполагал, что данная функция бросает какое-либо исключение и не ловил его при вызове, в результате чего оно долетело до main, где всё-таки был написан обработчик, или завершило программу. Или Вы вокруг каждой функции пишите catch-блоки?
обработчики надо писать там где можно обработать исключение.
в частности, вокруг каждой функции:
Здравствуйте, Nikita.Trophimov, Вы писали:
NT>Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение?
Код собирается на разных компиляторах, в том числе с поддержкой C++11. Использую BOOST_NOEXCEPT.
Типы исключений, по необходимости — в комментариях. Так как используется одна/две иерархии исключений, сами типы не так важны.
Exception specifications — в C++11 уже — deprecated. + читай Саттера.
Re: Как показать, что функция может бросать исключение
NT>В общем, хотелось бы услышать Ваши мнения по этому поводу.
Если функция какая поднимает исключенье
Вы об этом не шумите, лучше BOOL в result верните.
Будет юзер очень счастлив, когда в крэш влетит в релизе!
Ведь нежданные сюрпризы поднимают настроенье,
Очень людям это надо!
"Нормальные герои всегда идут в обход!"
Re: Как показать, что функция может бросать исключение
Здравствуйте, Nikita.Trophimov, Вы писали:
NT>Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение?
Ничего не делаю. Это не нужно в большинстве случаев.
Нужно только знать, бросает исключения функция или нет, а что конкретно она бросит, если может — это дело десятое.
И если бросает — обрабатываешь то, что можешь обработать на этом уровне (обычно ничего), остальное пробрасываешь наверх (опционально — завернув в другое исключение, если идет переброска между слоями программы — тогда сохранится стек исключений и информация не потеряется).
Имеет смысл документировать только те исключения, которые функция может бросить "сама", т.е. из своего собственного кода. Но при этом надо понимать, что исключения могут прилететь из любой другой функции, которую та функция зовет, и она никак этот дополнительный набор исключений не контролирует (если только это не пограничная функция данного слоя, отлавливающая все исключения и блокирующая/транслирующая их в свои).
EP>Код собирается на разных компиляторах, в том числе с поддержкой C++11. Использую BOOST_NOEXCEPT.
Т.е. Вы для всех функций, которые не бросают никаких исключений, указываете BOOST_NOEXCEPT, а для тех, которые что-то бросают, ничего не указываете, верно?
Re: Как показать, что функция может бросать исключение
Здравствуйте, Nikita.Trophimov, Вы писали:
NT>Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение?
В коментах написать о тех исключениях, которые может бросить сама функция.
NT>В общем, хотелось бы услышать Ваши мнения по этому поводу.
Мне нравится как это сделано в Java.
Sic luceat lux!
Re: Как показать, что функция может бросать исключение
Здравствуйте, Nikita.Trophimov, Вы писали:
NT>Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение? NT>* Пишу капсом комментарий / указываю в доках
Пишу комментарии.
И каждый день — без права на ошибку...
Re: Как показать, что функция может бросать исключение
Здравствуйте, Nikita.Trophimov, Вы писали:
NT>Что Вы делаете, когда хотите показать, что та или иная функция может бросать исключение?
... NT>exception specification не хочу использовать из-за возможности того, что человек, которому придётся поддерживать данный код, забудет посмотреть, какие типы исключений она может бросать, и вызовет std::unexpected.
NT>Если Вы выбрали последний вариант, то как Вы указываете, какие именно типы может выбрасывать данная функция?
NT>В общем, хотелось бы услышать Ваши мнения по этому поводу.
Imho, этот вопрос необходимо рассматривать в контексте применяемых подходов/практик/проекта.
И да, компилятор в случае с комментариями, особо не поможет...
Некоторые дополнительные политики:
* Запрещены все исключения, которые имеют кидающий конструктор копирования (здесь требуется инспекция реализаций стандартных исключений)
* Запрещено возбуждение исключений при нарушении предусловий (no holy wars, pls). Для проверки предусловий используются только стандартные assert'ы, иногда более агрессивные версии с __assume(MSVC specific), бан на std::logic_error.
* Разрешено кидать только std::runtime_error (с учетом первого пункта) или наследников, и только в том случае, если функция не может обеспечить выполнение постусловий по некоторым причинам, которые от нее не зависят.
* std::bad_alloc рассматривается как реально возможное исключение, причем оно несколько отлично от runtime_error по методам обработки, соответственно:
* Использование 'catch(const std::exception&)' подвергается более строгому review, так так ловит в т.ч. и std::bad_alloc.
* Определена политика действий в том случае, если при возникновении исключения необходимо получить и прицепить к нему дополнительную информацию, но это в свою очередь может также привести к исключению (варианты — аварийное завершение, потеря первоначального исключения, потеря дополнительной информации, различные трюки с попыткой сохранить оба исключения)
Re[2]: Как показать, что функция может бросать исключение
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>* Запрещено возбуждение исключений при нарушении предусловий (no holy wars, pls).
ЮЖ>* Разрешено кидать только std::runtime_error (с учетом первого пункта) или наследников, и только в том случае, если функция не может обеспечить выполнение постусловий по некоторым причинам, которые от нее не зависят.
А если может вернув фиктивные результаты?
И каждый день — без права на ошибку...
Re[2]: Как показать, что функция может бросать исключение
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>- обычно ничего, иногда тип гарантии.
+1
Я даже функцию специальную в нашем Doxygen сделал, exc_safety, чтоб сразу все видно было и форматировалось как надо.
Ну и чтоб два раз не вставать — thr_safety тоже, примерно о том же.
Здравствуйте, B0FEE664, Вы писали:
ЮЖ>>* Разрешено кидать только std::runtime_error (с учетом первого пункта) или наследников, и только в том случае, если функция не может обеспечить выполнение постусловий по некоторым причинам, которые от нее не зависят. BFE>А если может вернув фиктивные результаты?
В другом контесте такое поведение может быть допустимым, в описанном мною — нет, сама фраза противоречива.
Re[2]: Как показать, что функция может бросать исключение
Здравствуйте, rg45, Вы писали:
R>Очень интересная тема, с удовольствием почитаю то, что здесь напишут. От себя пока напишу только то, что суровая действительность давно уже научила не верить ни комментариям, ни документации. Верить можно только коду, пропущенному через компилятор.
Верить можно только Мюллеру, а в компиляторах бывают баги.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: Как показать, что функция может бросать исключение