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

Question

При написании кода безопасности исключений необходимо учитывать гарантию безопасности исключений (нет, базовая, сильная или безбросковая) для всех вызываемых функций. Поскольку компилятор не предлагает никакой помощи, я подумал, что соглашение об именовании функций может быть полезным здесь. Существует ли какой-либо установленный стандарт обозначений, указывающий уровень гарантии безопасности исключений, предлагаемый функциями? Я думал о чем-то похожем на венгерский:

void setFooB(Foo const& s); // B, offers basic guarantee
int computeSomethingS();    // S, offers strong guarantee
int getDataNT() throws();   // NT, offers no-throw
void allBetsAreOffN();      // N, offers no guarantee

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

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

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

Answer 1

Обычно я замечаю, что в комментариях (doxygen) исключается гарантия no throw , что я часто помечаю спецификацию throw() исключений тогда и только тогда, когда уверен, чтофункция гарантирует не генерировать, и безопасность исключений важна.

То есть я обычно больше беспокоюсь об исключениях в частях кода, где необработанное исключение может вызвать проблемы, и иметь дело сс этим локально (убедитесь, что ваш код безопасен для исключений другими средствами, такими как RAII, выполняя работу за пределами, а затем объединяя результаты с операцией no throw - т.е. no throw swap, которая является единственной функцией, которую я активно отмечаю какthrow().

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

Answer 2

Не думаю, что вам нужно делать что-то особенное.

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

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

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

Answer 3

Я думаю о добавлении

@par Exception Safety

Strong guarantee

в мои javadocs, где это уместно.

Answer 4

Я понимаю вашу готовность преуспеть, но я не уверен насчет такого соглашения об именах.

В общем, я настороженно отношусь к соглашениям об именах, которые не навязаны языком: они склонны становиться величайшими лжецами.

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

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