Стандарты программирования на С++. 101 правило и рекомендация

Александреску Андрей

При повторной генерации исключения

e

лучше просто писать оператор

throw;

вместо инструкции

throw e;

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

Примеры

Пример. Повторная генерация измененного исключения. При повторной генерации перехваченного исключения предпочтительно использовать простой оператор

throw;

.

catch (MyException& e) { // Перехват

неконстантной ссылки

 e.AppendContext("Перехват"); // Внесение изменения

 throw; // Повторная генерация

// модифицированного исключения

}

Ссылки

[Dewhurst03] §64-65 • [Meyers96] §13 • [Stroustrup00] §14.3 • [Vandevoorde03] §20

74. Уведомляйте об ошибках, обрабатывайте и преобразовывайте их там, где следует

Резюме

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

Обсуждение

Сообщайте об ошибке (т.е. пишите

throw

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

Обрабатывайте ошибку (т.е. пишите

catch

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

main

или потоков; см. рекомендацию 62) и для поглощения исключений в телах деструкторов и функций освобождения ресурсов.

Преобразовывайте ошибку (т.е. пишите

catch

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

• Для добавления высокоуровневого семантического значения. Например, в текстовом редакторе функция

Document::Open

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

• Для изменения механизма обработки ошибок. Например, в модуле, который внутренне использует исключения, но чей API в стиле С сообщает об ошибках посредством кодов ошибок, функции API должны перехватывать исключения и возвращать документированные коды ошибки, понятные вызывающему коду.

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

Исключения

Иногда

оказывается полезным перехватить и повторно генерировать ту же ошибку (т.е. воспользоваться

catch

с последующим

throw

) для контроля за ошибками, несмотря на то, что в действительности обработки ошибки при этом не происходит.

Ссылки

[Stroustrup00] §3.7.2, §14.7, §14.9 • [Sutter00] §8 • [Sutter04] §11 • [Sutter04b]

75. Избегайте спецификаций исключений

Резюме

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

Обсуждение

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

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

• неверным — в инструкции

typedef

для указателя на функцию;

• разрешенным — в точно таком же коде, но без использования

typedef

;

• необходимым — в объявлении виртуальной функции, которая перекрывает виртуальную функцию базового класса со спецификацией исключений;

• неявным и автоматическим — в объявлении конструкторов, операторов присваивания, операторов присваивания и деструкторов, когда они неявно генерируются компилятором.

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

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

try

/

catch

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