Соглашения об именах для методов, которые генерируют исключения (C ++)?

Question

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

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

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

Поскольку я чувствую себя разбитым и неуверенным в этом, я решил обратиться за советом отсюда:
Итак, использование таких соглашений об именах - хорошая идея / стоит усилий, и существуют ли установленные соглашения для этого?

Answer 1

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

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

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

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

Answer 2

Это может быть принято из C #.Например, для словаря у вас есть Add и TryAdd.

В моем примере я предоставляю dll и экспортирую функцию, которая ДОЛЖНА быть названа Start.Кроме того, поскольку это экспорт dll, он не должен бросать.

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

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

Answer 3

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

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

В C ++ 11 вы можете использовать спецификатор noexceptчто может быть полезно.