Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

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

Даже при наличии некоторых проблем с производительностью, отключите только те утверждения, которые действительно оказывают серьезное воздействие. Пример с программой сортировки, представленный выше, может быть самой важной частью вашего приложения и, наверное, должен работать быстро. Добавление процедуры проверки означает новое считывание данных, что может быть неприемлемо. Сделайте эту конкретную процедуру проверки необязательной [26] В языках программирования, имеющих своей основой язык С, можно использовать препроцессор или конструкцию с условными операторами с тем, чтобы указанные утверждения не носили обязательного характера. Во многих разработках происходит отключение генерации текста программы для макроса assert при установленном (или сброшенном) флажке этапа компиляции. Можно также поместить текст программы в пределах условного оператора if с постоянным условием, которое многие компиляторы (включая наиболее распространенные Java-системы) отбросят в ходе оптимизации.) , но оставьте в покое все остальные.

Становится как-то неловко, если программа, добавляемая для обнаружения ошибок, в результате создает новые. Это может происходить с утверждениями в том случае, если вычисление условия имеет побочные эффекты. Например, было бы дурным тоном написать на языке Java нечто вроде:

while (iter.hasMoreElements() {

Test.ASSERT(iter.nextElement() != null);

Object obj = iter.nextElement();

// ...

}

Вызов .nextElement() в ASSERT обладает побочным эффектом, заключающимся в перемещении указателя цикла за выбираемый элемент, так что цикл обрабатывает лишь половину элементов совокупности. Лучше было бы записать:

while (iter.hasMoreElements()) {

Object obj = iter.nextElement();

Test.ASSERT(obj != null);

//…

}

Эта проблема являются разновидностью так называемого «Heisen-bug» – процесса отладки, изменяющего поведение отлаживаемой системы (см. [URL 52]).

• Отладка

• Проектирование по контракту

• Балансировка ресурсов

• Программирование в расчете на совпадение

19. Быстрый тест на ощущение реальности. Какие из перечисленных «невозможных» событий могут случаться в реальности? (Ответ см. в Приложении В.)

1. Месяц, количество дней в котором меньше 28

2. Stat(».»,&sb)== –1 (т. е. невозможно обращение к текущему каталогу)

3. В языке С++: а = 2; b = 3; if (а + b != 5) exit(1);

4. Треугольник, сумма величин внутренних углов которого не равна 180°

5. Минута, состоящая не из 60 секунд

6. В языке Java: (а + 1) <= а

20. Разработайте несложный класс Java для проверки утверждений (Ответ см. в Приложении В.)

В разделе «Мертвые программы не лгут» высказано предложение считать хорошим тоном проверку всех возможных ошибок, в особенности возникающих неожиданно. Однако на практике это может привести к тому, что программа станет уродливой; нормальная логика вашей программы может сойти на нет из-за ее затуманивания процедурами обработки ошибок, особенно если вы являетесь приверженцем школы программирования, девиз которой звучит так: «В подпрограмме должен иметься один-единственный оператор return» (авторы не являются приверженцами указанной школы). Нам приходилось видеть текст программы, выглядевший следующим образом:

retcode = OK;

if (socket.read(name)!=OK) {

retcode = BAD_READ;

}

else

processName(name);

if (socket.read(address)!=OK) {

retcode = BAD READ;

}

else {

processAddress(address);

if (socket.read(telNo)!= OK) {

retcode= BAD_READ

}

else {

// etc, etc…

}

}

}

return retcode;

Но если язык программирования (no счастливой случайности) поддерживает исключения, то эту программу можно написать намного изящнее:

retcode = OK;

try {

socket.read(name);

process(name);

socket.read(address);

processAddress(address);

socket.read(telNo);

// etc, etc…

}

catch (lOException e) {

retcode = BAD_READ;

Logger.log("Error reading individual;» +e.getMessage());

}

return retcode;

Теперь схема управления отличается ясностью – вся обработка ошибок сосредоточена в одном-единственном месте.

Одна из проблем, связанных с исключениями, заключается в том, что необходимо знать, когда их можно использовать. Мы полагаем, что не стоит злоупотреблять исключениями для нормального хода выполнения программы; они должны быть зарезервированы для нештатных ситуаций. Предположите, что неперехваченное исключение прекратит работу вашей программы, и спросите себя: «А будет ли эта программа исполняться, если удалить все обработчики исключений?». Если ответ отрицательный, то вполне возможно, что исключения используются в обстоятельствах, их не требующих.