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

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

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

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

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

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

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

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

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

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

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

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

Везде.

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

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

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

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

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

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

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

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

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

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

Мы уже подчеркивали, что стратегия обработки ошибок может изменяться только на границах модулей (см. рекомендации 62 и 63). Каждый модуль должен последовательно использовать единую стратегию обработки ошибок внутри модуля (например, модули, написанные на С++, должны использовать исключения; см. рекомендацию 72), и последовательно пользоваться единой, хотя, возможно, иной стратегией обработки ошибок для своего интерфейса (например, модуль может предоставлять обычный API на языке С, чтобы обеспечить возможность его использования кодом, написанном на разных языках программирования; или использовать оболочку COM и, соответственно, исключения COM).

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

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