68. Широко применяйте assert для документирования внутренних допущений и инвариантов

68. Широко применяйте assert для документирования внутренних допущений и инвариантов

Резюме

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

Обсуждение

Очень трудно найти ошибку в своем коде, когда вы ищете ее; но во сто крат труднее найти ее, если вы считаете, что ее там нет.

— Стив Мак-Коннелл (Steve McConnell)

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

Рассматриваемые проверки обычно генерируют код только в режиме отладки (когда не определен макрос NDEBUG), так что от них можно освободиться при сборке окончательной версии программы. Широко используйте проверки в своих программах, но никогда не пишите выражений в assert, которые могут иметь побочное действие. При построении окончательной версии, когда будет определен макрос NDEBUG, проверки не будут генерировать никакого кода:

assert(++i < limit); // Плохо: i увеличивается только в

                     // отладочном режиме

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

Избегайте применения assert(false), лучше использовать assert(!"информационное сообщение"). Большинство компиляторов вставят строку в вывод сообщения об ошибке. Подумайте также о добавлении &&"информационное сообщение" к более сложным проверкам вместо комментария.

Рассмотрим определение вашего собственного assert. Стандартный макрос assert просто бесцеремонно завершает вашу программу с выводом сообщения в стандартный поток вывода. Ваша среда, вероятно, обладает расширенными возможностями отладки; пусть, например, она в состоянии автоматически запустить интерактивный отладчик. В этом случае вы можете определить собственный макрос MYASSERT и использовать его. Может также оказаться полезным оставить большинство проверок даже в окончательной версии программы (лучше не отключать проверки по соображениям эффективности, пока необходимость этого

отключения не будет точно доказана; см. рекомендацию 8), так что существенные преимущества может предоставить наличие различных "уровней проверки", некоторые из которых могут оставаться активными и в окончательной версии программы.

Проверки зачастую связаны с условиями, которые можно было бы протестировать во время компиляции, если бы язык был достаточно выразителен для этого. Например, ваш проект может полагаться на то, что каждый объект класса Employee имеет ненулевой идентификатор id_. В идеале компилятор мог бы анализировать конструктор Employee и его члены и доказать при помощи статического анализа, что указанное условие всегда выполняется. В реальной ситуации вы можете использовать assert(id_!=0) в реализации Employee:

unsigned int Employee::GetID() {

 assert(id_!=0 && "Employee ID должен быть ненулевым");

 return id_;

}

He используйте assert для сообщения об ошибках времени выполнения (см. рекомендации 70 и 72). Например, не следует применять assert, чтобы убедиться в корректной работе malloc, успешном создании окна или запуске потока программы. Однако можно использовать assert, чтобы убедиться, что API работает так, как документировано. Например, если вы вызываете некоторую функцию API, в документации на которую сказано, что она всегда возвращает положительное значение, но вы подозреваете наличие в ней ошибки — после вызова этой функции можно воспользоваться assert для проверки выполнения постусловия.

Не рекомендуется вместо проверок генерировать исключения, несмотря на то, что именно для этой цели был разработан стандартный класс std::logic_error. Главный недостаток использования исключений для сообщения о программных ошибках состоит в том, что при этом не требуется свертка стека — желательно вызвать отладчик именно в той строке, где обнаружено нарушение, с полным сохранением состояния программы.

Резюмируя: имеются ошибки, о которых вы знаете, что они могут произойти (см. рекомендации с 69 по 75). Все остальные ошибки произойти не должны, и если это все же случается — то это ошибка программиста. Для таких ошибок имеется assert.

Примеры

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

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