Типичные ошибки программирования

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

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

13.3. Исключение должно генерироваться только внутри блока try. Исключение сгенерированное вне блока try, вызывает обращение к terminate - прерыванию программы.

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

13.5. Задание разделяемого запятыми списка аргументов catch.

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

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

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

13.9. Предположение, что исключение, сгенерированное обработчиком catch, будет обработано этим или любым другим обработчиком, связанным с тем же блоком try, который сгенерировал первоначальное исключение.

13.10. Размещение пустого оператора throw вне обработчика catch; выполнение такого оператора throw вызовет обращение к terminate.

13.11. Генерация исключения, не перечисленного в спецификации исключений функции, вызывает обращение к unexpected.

Хороший стиль программирования

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

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

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

13.4. Избегайте имени Exception для любого класса исключения. Весьма вероятно, что это имя используется библиотеками, и возможно даже будет включено в развивающийся стандарт ANSI для С-Н-.

13.5. Привязка каждого типа ошибки времени выполнения к соответственно названному объекту исключения улучшает ясность программы.

Советы по повышению эффективности

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

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

Замечания по мобильности

13.1. Как уже было сказано, стандарт ANSI для C-I-I- еще не завершен и возможно, что особенности работы с исключениями, описанные в этой главе, могут еще развиваться далее в течение следующих нескольких лет. Когда мы завершали написание этой книги, главные продавцы трансляторов С-Н- начали поставлять версии с обработкой исключений. Опыт, полученный при работе с ними в течение нескольких следующих лет должен помочь в продвижении к стандарту.

Замечания по технике программирования

13.1. Поток управления со стандартными управляющими структурами вообще более ясен и более эффективен, чем применение исключений.

13.2. Обработка исключений особенно полезна для систем с отдельно разработанными компонентами. Это типично для больших программных комплексов. Обработка исключений позволяет проще объединять компоненты. Каждый компонент может сам осуществлять обнаружение исключительной ситуации отдельно от ее обработки.

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

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

13.4. Ключевым моментом в стиле обработки исключений в С-Ы- является то, что часть программы или системы, которая будет обрабатывать исключение, может быть совершенно отделена и удалена от части программы, которая обнаружила и возбудила исключение.

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

13.6. Может быть сгенерирован объект, не содержащий информацию для передачи; в этом случае обработчику достаточно простой информации о том, что сгенерировано исключение данного типа, чтобы правильно выполнить свою задачу.

13.7. Недостаток перехвата исключений с помощью catch (...) заключается в том, что вы обычно не можете знать, каков тип исключения. Другой недостаток заключается в том, что без поименованного параметра не существует никакого способа обратиться в обработчике исключения к объекту исключения.

13.8. Программист определяет последовательность, в которой перечисляются обработчики исключений. Эта последовательность может влиять на то, как обрабатываются исключения, возникающие в этом блоке try.

13.9. Самое лучшее - включить вашу стратегию обработки исключений в проектируемую систему до начала процесса проектирования. Трудно добавлять эффективную обработку исключений после того, как система реализована.

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

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