корректно вычленить ошибки из прочих ситуаций (см. рекомендацию 70). Если же это действительно ошибки, которые нарушают пред-, постусловия или инварианты, и они встречаются настолько часто — значит, у вашей программы имеются гораздо более серьезные проблемы, чем снижение производительности из-за обработки исключений.
Один из симптомов неверного употребления кодов ошибок — когда коду приложения приходится постоянно проверять тривиальные истинные условия, либо (что еще хуже) когда приложение не проверяет коды ошибок, которые должно проверять.
Симптом злоупотребления исключениями — когда код приложения генерирует и перехватывает исключения настолько часто, что количества успешных и неуспешных выполнений try
-блока оказываются величинами одного порядка. Такой catch
-блок либо в действительности обрабатывает не истинные ошибки (которые нарушают пред-, постусловия или инварианты), либо у вашей программы имеются серьезные проблемы.
find_first_of
в рекомендации 70.)
Обратитесь также к примерам рекомендации 70, заменяя в их тексте 'сообщение об ошибке' на 'генерация исключения'.
В редких случаях можно рассмотреть возможность использования кодов ошибок, если оказываются выполнены следующие условия.
В некоторых очень редких случаях некоторые программы, работающие в реальном времени, могут собираться с отключенной обработкой исключений из-за того, что механизм этой обработки, предлагаемый компилятором, имеет в худшем случае время работы, которое не позволяет ключевым операциям выполняться в реальном времени. Конечно, такое отключение обработки исключений означает, что язык и стандартная библиотека не будут уведомлять об ошибках стандартным способом (или не будут уведомлять об ошибках вообще — см. документацию на ваш компилятор), и механизм уведомления об ошибках в вашем проекте должен быть основан не на исключениях, а на кодах ошибок. Трудно преувеличить всю нежелательность принятия такого решения. Перед тем как решиться на такой шаг, вы должны детально проанализировать, каким образом будет выполняться уведомление об ошибках в конструкторах и операторах и как предложенная схема будет работать на вашем компиляторе. Если после серьезного и глубокого анализа вы все же решите отключить механизм обработки исключений, то не делайте это во всем проекте; постарайтесь ограничиться как можно меньшим количеством модулей, собрав в них наиболее важные и чувствительные ко времени выполнения операции.
73. Генерируйте исключения по значению, перехватывайте — по ссылке
Генерируйте исключения по значению (не через указатель) и перехватывайте их как ссылки (обычно константные). Эта комбинация наилучшим образом соответствует семантике исключений. При повторной генерации перехваченного исключения предпочтительно использовать просто оператор throw;
, а не инструкцию throw e;
.
При генерации исключения генерируйте его по значению. Избегайте использовать исключение- указатель, поскольку в этом случае вам придется столкнуться с массой вопросов управления памятью: вы не можете генерировать исключение-указатель на значение в стеке, поскольку до того, как указатель достигнет точки назначения, стек будет свернут. Вы можете генерировать исключение-указатель на динамически выделенную память (если, конечно, ошибка, о которой вы сообщаете, не состоит в нехватке памяти), но при этом вы возлагаете на catch
-блок задачу по освобождению выделенной памяти. Если вы уверены, что вам надо генерировать именно указатель, подумайте, нельзя ли заменить его интеллектуальным указателем типа shared_ptr<T>
вместо обычного T*
.
При генерации по значению компилятор сам отвечает за запутанный процесс управления памятью, выделенной генерируемому объекту. Все, что требуется от вас, — это принять меры для гарантии того, что копирующий конструктор класса вашего исключения не может генерировать исключений (см. рекомендацию 32).
Если только вы не генерируете интеллектуальный указатель, который добавляет уровень косвенности для сохранения полиморфизма, перехватывать исключения следует по ссылке. Перехват по значению приведет к срезке в точке перехвата (см. рекомендацию 54), что лишит вас обычно весьма важного качества полиморфизма объекта исключения. Перехват по ссылке сохраняет полиморфизм объекта исключения.
При повторной генерации исключения e
лучше просто писать оператор throw;
вместо инструкции throw e;
. Дело в том, что первый способ всегда сохраняет полиморфизм объекта повторно генерируемого исключения.
throw;
.
catch (MyException& e) { // Перехват неконстантной ссылки
e.AppendContext('Перехват'); // Внесение изменения
throw; // Повторная генерация
// модифицированного исключения
}