Пример. Проверка базовых допущений. Все мы сталкивались с ситуациями, когда происходило что-то, что "ну никак не может произойти". Но часто даже собственный опыт мало чему учит, и через некоторое время опять начинается — "это значение может быть только положительным!", "совершенно очевидно, что этот указатель не нулевой!"... Разработка программного обеспечения — работа сложная, и в программе, в которую вносятся изменения, может произойти все, что угодно. Проверки предназначены для того, чтобы убедиться в справедливости ваших предположений. Не стесняйтесь проверять тавтологии, которые не в состоянии обеспечить система:

string Date::DayOfWeek() const {

 // проверка инвариантов

 assert(day_ > 0 && day_ <= 31);

 assert (month_ > 0 && month_ <= 12);

 // ...

}

Ссылки

[Abrahams01b] • [Alexandrescu03b] • [Alexandrescu03c] • [Allison98] §13 • [Cargill92] pp. 34-35 • [Cline99] §10.01-10 • [Dewhurst03] §28 • [Keffer95] pp. 24-25 • [Lakos96] §2.6, §10.2.1 • [McConnell93] §5.6 • [Stroustrup00] §24.3.7, §E.2, §E.3.5, §E.6 • [Sutter00] §47

69. Определите разумную стратегию обработки ошибок и строго ей следуйте

Резюме

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

• Идентификация: какие условия являются ошибкой.

• Строгость: насколько важна каждая ошибка.

• Обнаружение: какой код отвечает за обнаружение ошибки.

• Распространение: какой механизм используется для описания и распространения уведомления об ошибке в каждом модуле.

• Обработка: какой код отвечает за выполнение действий, связанных с ошибкой.

• Уведомление: каким образом информация об ошибке вносится в журнальный файл или производится уведомление пользователя программы.

Изменяйте механизмы обработки ошибок только в пределах границ модуля.

Обсуждение

В этой рекомендации мы рассматриваем ошибки времени выполнения, возникновение которых не связано с неверным кодированием (таким ошибкам посвящена рекомендация 68).

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

Везде.

• Определение ошибок. Для каждой сущности (например, для каждой функции, класса, модуля) документируйте внутренние и внешние инварианты.

Для каждой функции.

• Определение ошибок. Для каждой функции документируйте ее пред- и постусловия, инварианты, за которые она отвечает, и гарантии безопасности, которые она поддерживает (см. рекомендации 70 и 71). Заметим, что деструкторы и функции освобождения ресурсов должны всегда поддерживать гарантию бессбойности, поскольку в противном случае часто невозможно надежно и безопасно выполнить освобождение захваченных ресурсов (см. рекомендацию 51).

Для каждой ошибки (см. определение "ошибки" в рекомендации 70).

• Серьезность ошибки и категоризация. Для каждой ошибки определите уровень серьезности. Желательно предоставить способ тонкой настройки диагностики для определенных категорий и уровней ошибок.

• Обнаружение ошибок. Для каждой ошибки документируйте, какой именно код отвечает за ее обнаружение, следуя советам рекомендации 70.

• Обработка ошибок. Для каждой ошибки определите код, который отвечает за ее обработку, следуя советам рекомендации 74.

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

Для каждого модуля.

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