Стандарты программирования на С++. 101 правило и рекомендация
Шрифт:
Главный потенциальный недостаток обработки исключений заключается в том, что требует от программиста хороших знаний о некоторых идиомах, возникающих в результате вынесения исключений из основного потока управления. Например, деструкторы и функции освобождения ресурсов не должны генерировать исключения (см. рекомендацию 51), а промежуточный код должен быть корректен при наличии исключений (см. рекомендацию 71 и ссылки); распространенная идиома для достижения этого заключается в отдельном выполнении всей работы, которая может привести к генерации исключений, и только после успешного завершения результаты работы принимаются, и состояние программы модифицируется с использованием только тех операций, которые предоставляют гарантию бессбойности (см. рекомендацию 51 и [Sutter00] §9-10, §13). Однако использование кодов ошибок также имеет собственные идиомы. Просто
Обычно использование обработки исключений не приводит к снижению производительности. Для начала заметим, что вы всегда должны включать поддержку обработки исключений в вашем компиляторе, даже если по умолчанию она отключена; в противном случае вы не сможете получить предусмотренное стандартом поведение и уведомление об ошибках от таких операций С++, как оператор new или операции стандартной библиотеки наподобие вставок в контейнер (см. раздел исключений в данной рекомендации).
[Небольшое отступление. Включение поддержки обработки исключений может быть реализовано так, что оно увеличит размер выполнимого файла (что неизбежно), но при этом практически не повлияет на производительность приложения при отсутствии сгенерированных исключений, причем некоторые компиляторы именно так и поступают. Другие компиляторы приводят к определенным накладным расходам, в особенности при обеспечении режима безопасности для предотвращения атак посредством переполнения буфера в механизме обработки исключений. Однако имеются ли накладные расходы, связанные с механизмом обработки исключений, или нет — в любом случае, вы должны включить его, иначе вы не сможете получать сообщения об ошибках от языка программирования и стандартной библиотеки.]
При включенной поддержке обработки исключений компилятором разница в производительности между генерацией исключений и возвратом кода ошибки при нормальной работе (в отсутствие ошибок) обычно незначительна. Определенную разницу в производительности можно заметить только при ошибках, но если ошибки происходят так часто, что становится ощутимой разница в производительности — скорее всего, вы используете исключения для ситуаций, которые ошибками не являются, а значит, вы не смогли корректно вычленить ошибки из прочих ситуаций (см. рекомендацию 70). Если же это действительно ошибки, которые нарушают пред-, постусловия или инварианты, и они встречаются настолько часто — значит, у вашей программы имеются гораздо более серьезные проблемы, чем снижение производительности из-за обработки исключений.
Один из симптомов неверного употребления кодов ошибок — когда коду приложения приходится постоянно проверять тривиальные истинные условия, либо (что еще хуже) когда приложение не проверяет коды ошибок, которые должно проверять.
Симптом злоупотребления исключениями — когда код приложения генерирует и перехватывает исключения настолько часто, что количества успешных и неуспешных выполнений
Пример 1. Конструкторы (ошибка инварианта). Если конструктор не способен успешно создать объект своего типа (что означает, что он не способен установить все инварианты нового объекта), он должен сгенерировать исключение. Верно и обратное — исключение, сгенерированное конструктором, означает, что конструирование объекта не выполнено и что время жизни объекта никогда не начиналось.
Пример 2. Успешный рекурсивный поиск в дереве. При поиске в дереве с использованием рекурсивного алгоритма может показаться заманчивой идея вернуть результат — и легко свернуть стек — генерируя исключение с результатом поиска. Но так делать не следует: исключение означает ошибку, а результат поиска ошибкой не является (см. [Stroustrup00]). (Заметим, что, конечно, неуспешный поиск также не является ошибкой в контексте функции поиска; см. пример с функцией
Обратитесь также к примерам рекомендации 70, заменяя в их тексте "сообщение об ошибке" на "генерация исключения".
В редких случаях можно
• Не применимы преимущества исключений. Например, вы знаете, что практически всегда ошибка будет обрабатываться непосредственно вызывающим кодом, так что распространение ошибки никогда (или практически никогда) не будет востребовано. Это весьма редкая ситуация, поскольку обычно вызываемая функция не имеет достаточной информации о том, какой код будет ее вызывать.
• Измерения показывают наличие реального снижения производительности при использовании исключений по сравнению с кодами ошибок. Обычно такое снижение производительности становится заметным при частой генерации исключений во внутреннем цикле; следует напомнить, что частая генерация исключений обычно говорит о том, что в качестве ошибки рассматривается ситуация, которая ошибкой не является.
В некоторых очень редких случаях некоторые программы, работающие в реальном времени, могут собираться с отключенной обработкой исключений из-за того, что механизм этой обработки, предлагаемый компилятором, имеет в худшем случае время работы, которое не позволяет ключевым операциям выполняться в реальном времени. Конечно, такое отключение обработки исключений означает, что язык и стандартная библиотека не будут уведомлять об ошибках стандартным способом (или не будут уведомлять об ошибках вообще — см. документацию на ваш компилятор), и механизм уведомления об ошибках в вашем проекте должен быть основан не на исключениях, а на кодах ошибок. Трудно преувеличить всю нежелательность принятия такого решения. Перед тем как решиться на такой шаг, вы должны детально проанализировать, каким образом будет выполняться уведомление об ошибках в конструкторах и операторах и как предложенная схема будет работать на вашем компиляторе. Если после серьезного и глубокого анализа вы все же решите отключить механизм обработки исключений, то не делайте это во всем проекте; постарайтесь ограничиться как можно меньшим количеством модулей, собрав в них наиболее важные и чувствительные ко времени выполнения операции.
[Alexandrescu03d] • [Allison98] §13 • [Stroustrup94] §16 • [Stroustrup00] §8.3.3, §14.1, §14.4-5, §14.9, §E.3.5 • [Sutter00] §8-19, §40-41, §47 • [Sutter02] §17-23 • [Sutter04] §11-16 • [Sutter04b]
73. Генерируйте исключения по значению, перехватывайте — по ссылке
Генерируйте исключения по значению (не через указатель) и перехватывайте их как ссылки (обычно константные). Эта комбинация наилучшим образом соответствует семантике исключений. При повторной генерации перехваченного исключения предпочтительно использовать просто оператор
При генерации исключения генерируйте его по значению. Избегайте использовать исключение-указатель, поскольку в этом случае вам придется столкнуться с массой вопросов управления памятью: вы не можете генерировать исключение-указатель на значение в стеке, поскольку до того, как указатель достигнет точки назначения, стек будет свернут. Вы можете генерировать исключение-указатель на динамически выделенную память (если, конечно, ошибка, о которой вы сообщаете, не состоит в нехватке памяти), но при этом вы возлагаете на
При генерации по значению компилятор сам отвечает за запутанный процесс управления памятью, выделенной генерируемому объекту. Все, что требуется от вас, — это принять меры для гарантии того, что копирующий конструктор класса вашего исключения не может генерировать исключений (см. рекомендацию 32).
Если только вы не генерируете интеллектуальный указатель, который добавляет уровень косвенности для сохранения полиморфизма, перехватывать исключения следует по ссылке. Перехват по значению приведет к срезке в точке перехвата (см. рекомендацию 54), что лишит вас обычно весьма важного качества полиморфизма объекта исключения. Перехват по ссылке сохраняет полиморфизм объекта исключения.