Программирование — страница 21 из 57

Ошибки

“Я понял, что с этого момента большую часть моей жизни

буду искать и исправлять свои же ошибки”.

Морис Уилкс (Maurice Wilkes, 1949)

В этой главе обсуждаются вопросы, связанные с корректностью программ, а также с ошибками и методами исправления ошибок. Если вы новичок, то обсуждение покажется вам несколько абстрактным, а иногда слишком подробным. Неужели обработка ошибок настолько важна? Да! И так или иначе вы должны научиться этому. Прежде чем приступать к разработке программ, предназначенных для других людей, мы попытаемся показать, что значит “думать, как программист”, т.е. как сочетать самые абстрактные стратегии с тщательным анализом деталей и альтернатив.

5.1. Введение

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

 Существует множество способов классификации ошибок. Рассмотрим пример.

• Ошибки во время компиляции. Это ошибки, обнаруженные компилятором. Их можно подразделить на категории в зависимости от того, какие правила языка он нарушают:

• синтаксические ошибки;

• ошибки, связанные с типами.

• Ошибки во время редактирования связей. Это ошибки, обнаруженные редактором связей при попытке объединить объектные файлы в выполняемый модуль.

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

• ошибки, обнаруженные компьютером (аппаратным обеспечением и/или операционной системой);

• ошибки, обнаруженные с помощью библиотеки (например, стандартной);

• ошибки, обнаруженные с помощью программы пользователя.

• Логические ошибки. Это ошибки, найденные программистом в поисках причины неправильных результатов.

Соблазнительно сказать, что задача программиста — устранить все ошибки. Разумеется, это было бы прекрасно, но часто этот идеал оказывается недостижимым. На самом деле для реальных программ трудно сказать, что подразумевается под выражением “все ошибки”. Например, если во время выполнения своей программы мы выдернем электрический шнур из розетки, то следует ли это рассматривать как ошибку и предусмотреть ее обработку? Во многих случаях совершенно очевидно, что ответ будет отрицательным, но в программе медицинского мониторинга или в программе, управляющей телефонными переключениями, это уже не так. В этих ситуациях пользователь вполне обоснованно может потребовать, чтобы система, частью которой является ваша программа, продолжала выполнять осмысленные действия, даже если исчезло энергопитание компьютера или космические лучи повредили его память. Основной вопрос заключается в следующем: должна ли программа сама обнаруживать ошибки?

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

1. Должна вычислять желаемые результаты при всех допустимых входных данных.

2. Должна выдавать осмысленные сообщения обо всех неправильных входных данных.

3. Не обязана обрабатывать ошибки аппаратного обеспечения.

4. Не обязана обрабатывать ошибки программного обеспечения.

5. Должна завершать работу после обнаружения ошибки.

Программы, для которых предположения 3–5 не выполняются, выходят за рамки рассмотрения нашей книги. В то же время предположения 1 и 2 являются частью основных профессиональных требований, а профессионализм — это именно то, к чему мы стремимся. Даже если мы не всегда соответствуем идеалу на 100%, он должен существовать.

При создании программы ошибки естественны и неизбежны. Вопрос лишь в том, как с ними справиться. По нашему мнению, при разработке серьезного программного обеспечения попытки обойти, найти и исправить ошибки занимают более 90% времени. Для программ, безопасность работы которых является первоочередной задачей, эти усилия займут еще больше времени. В маленьких программах легко избежать ошибок, но в больших вероятность ошибок возрастает.

 Мы предлагаем три подхода к разработке приемлемого программного обеспечения.

• Организовать программное обеспечение так, чтобы минимизировать количество ошибок.

• Исключить большинство ошибок в ходе отладки и тестирования.

• Убедиться, что оставшиеся ошибки не серьезны.

Ни один из этих подходов сам по себе не позволяет полностью исключить ошибки, поэтому мы будем использовать все три.

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

5.2. Источники ошибок

 Перечислим несколько источников ошибок.

• Плохая спецификация. Если мы слабо представляем себе, что должна делать программа, то вряд ли сможем адекватно проверить все ее “темные углы” и убедиться, что все варианты обрабатываются правильно (т.е. что при любом входном наборе данных мы получим либо правильный ответ, либо осмысленное сообщение об ошибке).

• Неполные программы. В ходе разработки неизбежно возникают варианты, которые мы не предусмотрели. Наша цель — убедиться, что все варианты обработаны правильно.

• Непредусмотренные аргументы. Функции принимают аргументы. Если функция принимает аргумент, который не был предусмотрен, то возникнет проблема, как, например, при вызове стандартной библиотечной функции извлечения корня из –1,2: sqrt(–1.2). Поскольку функция sqrt() получает положительную переменную типа double, в этом случае она не сможет вернуть правильный результат. Такие проблемы обсуждаются в разделе 5.5.3.

• Непредусмотренные входные данные. Обычно программы считывают данные (с клавиатуры, из файлов, из средств графического пользовательского интерфейса, из сетевых соединений и т.д.). Как правило, программы выдвигают к входным данным много требований, например, чтобы пользователь ввел число. А что, если пользователь введет не ожидаемое целое число, а строку “Отстань!”? Этот вид проблем обсуждается в разделах 5.6.3 и 10.6.

• Неожиданное состояние. Большинство программ хранит большое количество данных (“состояний”), предназначенных для разных частей системы. К их числу относятся списки адресов, каталоги телефонов и данные о температуре, записанные в объекты типа vector. Что произойдет, если эти данные окажутся неполными или неправильными? В этом случае разные части программы должны сохранять управляемость. Эти проблемы обсуждаются в разделе 26.3.5.

• Логические ошибки. Эти ошибки приводят к тому, что программа просто делает не то, что от нее ожидается; мы должны найти и исправить эти ошибки. Примеры поиска таких ошибок приводятся в разделе 6.6 и 6.9.

Данный список имеет практическое применение. Мы можем использовать его для контроля качества программы. Ни одну программу нельзя считать законченной, пока не исследованы все потенциально возможные источники ошибок. Этот список целесообразно иметь в виду уже в самом начале проекта, поскольку очень маловероятно, что поиск и устранение ошибок в программе, запущенной на выполнение без предварительного анализа, не потребует серьезной переработки.

5.3. Ошибки во время компиляции

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

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

В качестве примера рассмотрим вызовы следующей простой функции:

int area(int length, int width); // вычисление площади треугольника

5.3.1. Синтаксические ошибки

Что произойдет, если мы вызовем функцию area() следующим образом:

int s1 = area(7;   // ошибка: пропущена скобка )
int s2 = area(7)   // ошибка: пропущена точка с запятой ;
Int s3 = area(7);  // ошибка: Int — это не тип
int s4 = area('7); // ошибка: пропущена кавычка '

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

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

“Вы неправильно написали слово int; не следует употреблять прописную букву i.”

Скорее, он выразится так:

“Синтаксическая ошибка: пропущена ';' перед идентификатором 's3'”

“У переменной 's3' пропущен идентификатор класса или типа”

“Неправильный идентификатор класса или типа 'Int'”

Такие сообщения выглядят туманными, пока вы не научитесь их понимать и использовать. Разные компиляторы могут выдавать разные сообщения, анализируя один и тот же код. К счастью, вы достаточно скоро научитесь понимать эти сообщения без каких-либо проблем. В общем, все эти зашифрованные сообщения можно перевести так:

“Перед переменной s3 сделана синтаксическая ошибка, и надо что-то сделать либо с типом Int, либо с переменной s3.”

Поняв это, уже нетрудно решить проблему.

ПОПРОБУЙТЕ

Попробуйте скомпилировать эти примеры и проанализируйте ответы компиляторов.

5.3.2. Ошибки, связанные с типами

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

int x0 = arena(7); // ошибка: необъявленная функция
int x1 = area(7);  // ошибка: неправильное количество аргументов
int x2 = area("seven",2); // ошибка: первый аргумент
                          // имеет неправильный тип

Рассмотрим эти ошибки.

1. При вызове функции arena(7) мы сделали опечатку: вместо area набрали arena, поэтому компилятор думает, что мы хотим вызвать функцию с именем arena. (А что еще он может “подумать”? Только то, что мы сказали.) Если в программе нет функции с именем arena(), то вы получите сообщение об ошибке, связанной с необъявленной функцией. Если же в программе есть функция с именем arena, принимающая число 7 в качестве аргумента, то вы столкнетесь с гораздо худшей проблемой: программа будет скомпилирована как ни в чем ни бывало, но работать будет неправильно (такие ошибки называют логическими; см. раздел 5.7).

 2. Анализируя выражение area(7), компилятор обнаруживает неправильное количество аргументов. В языке C++ вызов каждой функции должен содержать ожидаемое количество аргументов, указанных с правильными типами и в правильном порядке. Если система типов используется корректно, она становится мощным инструментом, позволяющим избежать ошибок на этапе выполнения программы (см. раздел 14.1).

3. Записывая выражение area("seven",2), вы могли рассчитывать, что компилятор увидит строку "seven" и поймет, что вы имели в виду целое число 7. Напрасно. Если функция ожидает целое число, то ей нельзя передавать строку. Язык C++ поддерживает некоторые неявные преобразования типов (см. раздел 3.9), но не позволяет конвертировать тип string в тип int. Компилятор даже не станет угадывать, что вы имели в виду. А что вы могли бы ожидать от вызовов area("Hovel lane",2), area("7,2") и area("sieben","zwei")?

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

ПОПРОБУЙТЕ

Попробуйте скомпилировать эти примеры и проанализируйте сообщения компилятора. Придумайте еще несколько ошибок и проверьте их с помощью компилятора.

5.3.3. Не ошибки

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

int x4 = area(10,–7); // OK: но что представляет собой прямоугольник,
                      // у которого ширина равна минус 7?
int x5 = area(10.7,9.3);  // OK: но на самом деле вызывается area(10,9)
char x6 = area(100,9999); // OK: но результат будет усечен

Компилятор не выдаст никаких сообщений о переменной x4. С его точки зрения вызов area(10,–7) является правильным: функция area() запрашивает два целых числа, и вы их ей передаете; никто не говорил, что они должны быть положительными.

Относительно переменной x5 хороший компилятор должен был бы предупредить, что значения типа double, равные 10.7 и 9.3, будут преобразованы в значения типа int, равные 10 и 9 (см. 3.9.2). Однако (устаревшие) правила языка утверждают, что вы можете неявно преобразовать переменную типа double в переменную типа int, поэтому у компилятора нет никаких оснований отвергать вызов area(10.7,9.3).

Инициализация переменной x6 представляет собой вариант той же проблемы, что и вызов area(10.7,9.3). Значение типа int, возвращенное после вызова area(100,9999), вероятно, равное 999900, будет присвоено переменной типа char. В итоге, скорее всего, в переменную x6 будет записано “усеченное” значение –36. И опять-таки хороший компилятор должен выдать предупреждение, даже если устаревшие правила языка позволяют ему не делать этого.

По мере приобретения опыта вы научитесь использовать как сильные, так и слабые стороны компилятора. Однако не будьте слишком самоуверенными: выражение “программа скомпилирована” вовсе не означает, что она будет выполнена. Даже если она будет запущена на выполнение, то, как правило, сначала будет выдавать неправильные результаты, пока вы не устраните все логические недостатки.

5.4. Ошибки во время редактирования связей

 Любая программа состоит из нескольких отдельно компилируемых частей, которые называют единицами трансляции (translation units). Каждая функция в программе должна быть объявлена с теми же самыми типами, которые указаны во всех единицах трансляции, откуда она вызывается. Для этого используются заголовочные файлы (подробно о них речь пойдет в разделе 8.3). Кроме того, каждая функция должна быть объявлена в программе только один раз. Если хотя бы одно из этих правил нарушено, то редактор связей выдаст ошибку. Способы исправления ошибок во время редактирования связей рассматриваются в разделе 8.3. А пока рассмотрим пример программы, которая порождает типичную ошибку на этапе редактирования связей.

int area(int length, int width); // вычисляет площадь прямоугольника
int main()
{
  int x = area(2,3);
}

Если функция area() не объявлена в другом исходном файле и не связана с нашим файлом с помощью редактора связей, то он сообщит об отсутствии объявления функции area().

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

int area(int x, int y) { /* ... */ } // "наша" функция area()

Функции с таким же именем, но с другими типами аргументов будут проигнорированы.

double area(double x, double y) { /* ... */ }   // не "наша" area()
int area(int x, int y, char unit) { /* ... */ } // не "наша" area()

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

Как указывалось выше, правила связывания функций распространяются и на все другие сущности программы, например, на переменные и типы: каждая сущность с заданным именем должна быть определена только один раз, но объявлять ее можно сколько угодно, причем все эти объявления должны быть точно согласованными по типам. Детали изложены в разделах 8.2 и 8.3.

5.5. Ошибки во время выполнения программы

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

int area(int length, int width) // Вычисляем площадь прямоугольника
{
  return length*width;
}

int framed_area(int x, int y) // Вычисляем площадь,
                              // ограниченную рамкой
{
  return area(x–2,y–2);
}

int main()
{
  int x = –1;
  int y = 2;
  int z = 4;
  // ...
  int area1 = area(x,y);
  int area2 = framed_area(1,z);
  int area3 = framed_area(y,z);
  double ratio = double(area1)/area3; // Преобразуем к типу double,
                                      // чтобы выполнить деление
                                      //
 с плавающей точкой
}

Для того чтобы сделать проблемы менее очевидными и усложнить задачу компилятора, в качестве аргументов мы решили использовать переменные x, y и z, а не непосредственные числа. Однако эти вызовы функций возвращают отрицательные числа, присвоенные переменным area1 и area2. Можно ли принять эти ошибочные результаты, противоречащие законам математики и физики? Если нет, то где следует искать ошибку: в модуле, вызвавшем функцию area(), или в самой функции? И какое сообщение об ошибке следует выдать?

Прежде чем пытаться ответить на эти вопросы, проанализируем вычисление переменной ratio в приведенном выше коде. Оно выглядит довольно невинно. Вы заметили, что с этим кодом что-то не так? Если нет, посмотрите снова: переменная area3 будет равна 0, поэтому в выражении double(area1)/area3 возникает деление на нуль. Это приводит к ошибке, обнаруживаемой аппаратным обеспечением, которое прекращает выполнение программы, выдав на экран довольно непонятное сообщение. Вы и ваши пользователи будете сталкиваться с такими проблемами постоянно, если не научитесь выявлять и исправлять ошибки, возникающие на этапе выполнения программы. Большинство людей нервно реагируют на такие сообщения аппаратного обеспечения, так как им сложно понять, что происходит, когда на экране появляется сообщение вроде “Что-то пошло не так!” Этого недостаточно для того, чтобы предпринять какие-то конструктивные действия, поэтому пользователи злятся и проклинают программиста, написавшего такую программу.

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

1. Следует исправить ошибку в модуле, вызывающем функцию area().

2. Позволить функции area() (вызываемой функции) выполнять вычисления с неправильными аргументами.

5.5.1. Обработка ошибок в вызывающем модуле

Сначала рассмотрим первую альтернативу (“Берегись, пользователь!”). Именно ее нам следовало бы принять, например, если бы функция area() была библиотечной функцией, которую невозможно модифицировать. Как бы то ни было, эта ситуация является самой распространенной.

Предотвратить ошибку при вызове функции area(x,y) в модуле main() относительно просто:

if (x<=0) error("неположительное x");
if (y<=0) error("неположительное y");
int area1 = area(x,y);

Действительно, остается только решить, что делать, обнаружив ошибку. Здесь мы решили вызвать функцию error(), которая должна сделать что-то полезное. В заголовочном файле std_lib_facilities.h действительно описана функция error(), которая по умолчанию останавливает выполнение программы, сопровождая это сообщением системы и строкой, которая передается как аргумент функции error(). Если вы предпочитаете писать свои собственные сообщения об ошибках или предпринимать другие действия, то можете перехватывать исключение runtime_error (разделы 5.6.2, 7.3, 7.8, Б.2.1). Этого достаточно для большинства несложных программ.

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

if (x<=0 || y<=0) error("неположительный аргумент функции area()");
// || значит ИЛИ
int area1 = area(x,y);

Для того чтобы полностью защитить функцию area() от неправильных аргументов, необходимо исправить вызовы функции framed_area(). Этот фрагмент кода можно переписать следующим образом:

if (z<=2)
  error("неположительный второй аргумент функции area() \\
         при вызове из функции framed_area()");
int area2 = framed_area(1,z);
if (y<=2 || z<=2)
  error("неположительный аргумент функции area()\\
         при вызове из функции framed_area()");
int area3 = framed_area(y,z);

Это не только запутанно, но и неверно в принципе. Такой код можно написать, лишь точно зная, как функция framed_area() использует функцию area().

Мы должны знать, что функция framed_area() вычитает 2 из каждого аргумента. Но мы не должны знать такие детали! А что, если кто-нибудь изменит функцию framed_area() и вместо 2 станет вычитать 1?

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

const int frame_width = 2;
int framed_area(int x, int y) // вычисляем площадь,
                              // ограниченную рамкой
{
  return area(x–frame_width,y–frame_width);
}

Это имя можно использовать в коде, вызывающем функцию framed_area().

if (1–frame_width<=0 || z–frame_width<=0)
  error("неположительный второй аргумент функции area() \\
         при вызове из функции framed_area()");
int area2 = framed_area(1,z);
if (y–frame_width<=0 || z–frame_width<=0)
  error("неположительный аргумент функции area() \\
         при вызове из функции framed_area()");
int area3 = framed_area(y,z);

Взгляните на этот код! Вы уверены, что он правильный? Он вам нравится? Легко ли его читать? Действительно, он уродлив (а значит, подвержен ошибкам). В результате наших неуклюжих попыток размер кода увеличился втрое, а детали реализации framed_area() всплыли наружу.

Существует более правильное решение!

Посмотрите на исходный код.

int area2 = framed_area(1,z);
int area3 = framed_area(y,z);

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

5.5.2. Обработка ошибок в вызываемом модуле

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

int framed_area(int x, int y) // вычисляем площадь, ограниченную рамкой
{
  const int frame_width = 2;
  if (x–frame_width<=0 || y–frame_width<=0)
    error("неположительный аргумент функции area() \\
           при вызове из функции framed_area()");
  return area(x–frame_width,y–frame_width);
}

Это решение выглядит неплохо, и нам больше нет необходимости писать проверку для каждого вызова функции framed_area(). Для полезной функции, которая 500 раз вызывается в крупной программе, это большое преимущество. Более того, если обработка ошибок по какой-то причине изменится, нам будет достаточно изменить код только в одном месте.

Отметим нечто интересное: мы почти бессознательно заменили подход “вызывающий модуль должен сам проверять аргументы” на подход “функция должна проверять свои собственные аргументы”. Одним из преимуществ второго подхода является то, что проверка аргументов осуществляется в единственном месте. Теперь необязательно просматривать вызовы функции по всей программе. Более того, проверка производится именно там, где эти аргументы используются, поэтому мы имеем всю информацию, необходимую для проверки.

Итак, применим найденное решение к функции area().

int area(int length, int width) // вычисляем площадь прямоугольника
{
  if (length<=0 || width <=0)
    error("неположительный аргумент area()");
  return length*width;
}

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

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

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

• Вызываемая функция не знает, что делать при выявлении ошибки. Эта ситуация типична для библиотечных функций. Автор библиотеки может выявить ошибку, но только вы знаете, что в таком случае следует делать.

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

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

 Итак, что делать? Проверять аргументы в функции, если у вас нет веских причин поступать иначе.

После обсуждения некоторых тем, связанных с этим вопросом, мы вернемся к нему в разделе 5.10.

5.5.3. Сообщения об ошибках

Рассмотрим немного иной вопрос: что делать, если вы проверили набор аргументов и обнаружили ошибку? Иногда можно вернуть сообщение “Неправильное значение”. Рассмотрим пример.

// Попросим пользователя ввести да или нет;
// Символ 'b' означает неверный ответ (т.е. ни да ни нет)
char ask_user(string question)
{
  cout << question << "? (да или нет)\n";
  string answer = " ";
  cin >> answer;
  if (answer =="y" || answer=="yes") return 'y';
  if (answer =="n" || answer=="no") return 'n';
  return 'b'; // 'b', если "ответ неверный"
}

// Вычисляет площадь прямоугольника;
// возвращает –1, если аргумент неправильный
int area(int length, int width)
{
  if (length<=0 || width <=0) return –1;
    return length*width;
}

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

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

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

• Многие функции не имеют возможность возвращать дополнительные значения, чтобы сообщить об ошибке. Например, функция, считывающая целое число из потока ввода (скажем, оператор >> потока cin), может возвращать любое целое число, поэтому использовать целое число в качестве индикатора ошибки бессмысленно.

Вторая ситуация, в которой проверка в вызывающем модуле не выполняется, может легко привести к неожиданностям

Рассмотрим пример.

int f(int x, int y, int z)
{
  int area1 = area(x,y);
  if (area1<=0) error("Неположительная площадь");
  int area2 = framed_area(1,z);
  int area3 = framed_area(y,z);
  double ratio = double(area1)/area3;
  // ...
}

Вы заметили ошибку? Такие ошибки трудно выявить, так как сам код является правильным: ошибка заключается в том, что программист не включил в него проверку.

ПОПРОБУЙТЕ

Выполните эту программу при разных значениях. Выведите на печать значения переменных area1, area2, area3 и ratio. Вставьте в программу больше проверок разных ошибок. Вы уверены, что перехватите все ошибки? Это вопрос без подвоха; в данном конкретном примере можно ввести правильный аргумент и перехватить все возможные ошибки.

Существует другой способ решить описанную проблему: использовать исключения (exceptions).

5.6. Исключения

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

Основная идея заключается в следующем: если функция обнаруживает ошибку, которую не может обработать, она не выполняет оператор return как обычно, а генерирует исключение с помощью оператора throw, показывая, что произошло нечто неправильное.

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

Мы еще вернемся к исключениям позже (в главе 19), чтобы использовать их немного более сложным способом.

5.6.1. Неправильные аргументы

Рассмотрим вариант функции area(), использующий исключения.

class Bad_area { }; // Тип, созданный специально для сообщений
                    // об ошибках,
      // возникших в функции area()
      // Вычисляет площадь прямоугольника;
      // при неправильном аргументе генерирует исключение Bad_area
int area(int length, int width)
{
  if (length<=0 || width<=0) throw Bad_area();
  return length*width;
}

Иначе говоря, если аргументы правильные, то программа всегда возвращает площадь прямоугольника, а если нет, то выходим из функции area() с помощью оператора throw, надеясь найти ответ в одном из разделов catch. Bad_area — это новый тип, предназначенный исключительно для генерирования исключений в функции area(), так, чтобы один из разделов catch распознал его как исключение, сгенерированное функцией area(). Типы, определенные пользователями (классы и перечисления), обсуждаются в главе 9. Обозначение Bad_area() означает “Создать объект типа Bad_area”, а выражение throw Bad_area() означает “Создать объект типа Bad_area и передать его (throw) дальше”.

Теперь функцию можно написать так:

int main()
try {
  int x = –1;
  int y = 2;
  int z = 4;
  // ...
  int area1 = area(x,y);
  int area2 = framed_area(1,z);
  int area3 = framed_area(y,z);
  double ratio = area1/area3;
}
catch (Bad_area) {
  cout << "Ой! Неправильный аргумент функции area()\n";
}

Во-первых, этот фрагмент программы обрабатывает все вызовы функции area() как вызов из модуля main(), так и два вызова из функции framed_area(). Во-вторых, обработка ошибки четко отделена от ее выявления: функция main() ничего не знает о том, какая функция выполнила инструкцию throw Bad_area(), а функция area() ничего не знает о том, какая функция (если такая существует) должна перехватывать исключения Bad_area, которые она генерирует. Это разделение особенно важно в крупных программах, написанных с помощью многочисленных библиотек. В таких программах ни один человек не может обработать ошибку, просто поместив некоторый код в нужное место, поскольку никто не может модифицировать код одновременно в приложении и во всех библиотеках.

5.6.2. Ошибки, связанные с диапазоном

Большинство реальных программ работает с наборами данных. Иначе говоря, они используют разнообразные таблицы, списки и другие структуры данных. В контексте языка С++ наборы данных часто называют контейнерами (containers). Наиболее часто используемым контейнером стандартной библиотеки является тип vector, введенный в разделе 4.6.

Объект типа vector хранит определенное количество элементов, которое можно узнать с помощью его функции-члена size(). Что произойдет, если мы попытаемся использовать элемент с индексом, не принадлежащим допустимому диапазону [0:v.size()]? Обычное обозначение [low:high] означает, что индексы могут принимать значения от low до high-1, т.е. включая нижнюю границу, но исключая верхнюю.

Прежде чем ответить на этот вопрос, необходимо ответить на другой: “Как это может быть?” Помимо всего прочего, известно, что индекс вектора v должен лежать в диапазоне [0:v.size()], поэтому достаточно просто убедиться в этом!

Легко сказать, но трудно сделать. Рассмотрим следующую вполне разумную программу:

vector v; // вектор целых чисел
int i;
while (cin>>i) v.push_back(i);    // вводим значения в контейнер
for (int i = 0; i<=v.size(); ++i) // печатаем значения
  cout << "v[" << i <<"] == " << v[i] << endl;

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

Мы использовали 0 и size(), чтобы попытаться гарантировать, что индекс i всегда будет находиться в допустимом диапазоне, когда мы обратимся к элементу v[i]. К сожалению, мы сделали ошибку. Посмотрите на цикл for: условие его завершения сформулировано как i<=v.size(), в то время как правильно было бы написать i. В результате, прочитав пять чисел, мы попытаемся вывести шесть. Мы попытаемся обратиться к элементу v[5], индекс которого ссылается за пределы вектора. Эта разновидность ошибок настолько широко известна, что даже получила несколько названий: ошибка занижения или завышения на единицу (off-by-obe error), ошибка диапазона (range error), так как индекс не принадлежит допустимому диапазону вектора, и ошибка пределов (bounds error), поскольку индекс выходит за пределы вектора.

Эту ошибку можно спровоцировать намного проще.

vector v(5);
int x = v[5];

Однако мы сомневаемся, что вы признаете такой пример реалистичным и заслуживающим внимания. Итак, что же произойдет на самом деле, если мы сделаем ошибку диапазона? Операция доступа по индексу в классе vector знает размер вектора, поэтому может проверить его (и действительно, делает это; см. разделы 4.6 и 19.4). Если проверка заканчивается неудачей, то операция доступа по индексу генерирует исключение типа out_of_range. Итак, если бы ошибочный код, приведенный выше, являлся частью какой-то программы, перехватывающей исключения, то мы получили бы соответствующее сообщение об ошибке.

int main()
try {
  vector v; // вектор целых чисел
  int x;
  while (cin>>x) v.push_back(x);    // записываем значения
  for (int i = 0; i<=v.size(); ++i) // выводим значения
    cout << "v[" << i <<"] == " << v[i] << endl;
} catch (out_of_range) {
    cerr << "Ой! Ошибка диапазона \n";
    return 1;
  } catch (...) { // перехват всех других исключений
   cerr << "Исключение: что-то не так \n";
   return 2;
}

Обратите внимание на то, что ошибка диапазона на самом деле является частным случаем ошибки, связанной с аргументами, которую мы обсудили в разделе 5.5.2. Не доверяя себе, мы поручили проверку диапазона индексов вектора самой операции доступа по индексу. По очевидным причинам оператор доступа по индексу (vector::operator[]) сообщает об ошибке, генерируя исключение. Что еще может произойти? Оператор доступа по индексу не имеет представления о том, что бы мы хотели в этой ситуации делать. Автор класса vector даже не знает, частью какой программы может стать его код.

5.6.3. Неправильный ввод

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

Рассмотрим фрагмент кода, в котором вводится число с плавающей точкой.

double d = 0;
cin >> d;

Мы можем проверить, успешной ли оказалась последняя операция, подвергнув проверке поток cin.

if (cin) {
  // все хорошо, и мы можем считывать данные дальше
}
else {
  // последнее считывание не было выполнено,
  // поэтому следует что-то сделать
}

Существует несколько возможных причин сбоя при вводе данных. Одна из них — тип данных, которые мы пытаемся считать, — отличается от типа double. На ранних стадиях разработки мы часто хотим просто сообщить, что нашли ошибку и прекратить выполнение программы, потому что еще не знаем, как на нее реагировать. Иногда мы впоследствии возвращаемся к этому фрагменту и уточняем свои действия. Рассмотрим пример.

double some_function()
{
 double d = 0;
 cin >> d;
 if (!cin)
   error("невозможно считать число double в 'some_function()'");
   // делаем что-то полезное
}

Строку, переданную функции error(), можно вывести на печать для облегчения отладки или для передачи сообщения пользователю. Как написать функцию error() так, чтобы она оказалась полезной для многих программ? Она не может возвращать никакого значения, потому что неизвестно, что с ним делать дальше. Вместо этого лучше, чтобы функция error() прекращала выполнение программы после получения сообщения об ошибке. Кроме того, перед выходом иногда следует выполнить определенные несложные действия, например, оставить окно с сообщением активным достаточно долго, чтобы пользователь мог прочесть сообщение. Все это вполне естественно для исключений (подробнее об этом — в разделе 7.3).

В стандартной библиотеке определено несколько типов исключений, таких как out_of_range, генерируемых классом vector. Кроме того, в этой библиотеке есть исключение runtime_error, идеально подходящее для наших нужд, поскольку в ней хранится строка, которую может использовать обработчик ошибки.

Итак, нашу простую функцию error() можно переписать следующим образом:

void error(string s)
{
  throw runtime_error(s);
}

Когда нам потребуется поработать с исключением runtime_error, мы просто перехватим его. Для простых программ перехват исключения runtime_error в функции main() является идеальным.

int main()
try {
  // наша программа
  return 0; // 0 означает успех
}
catch (runtime_error& e) {
  cerr << "runtime error: " << e.what() << '\n';
  keep_window_open();
  return 1; // 1 означает сбой
}

Вызов e.what() извлекает сообщение об ошибке из исключения runtime_error.

Символ & в выражении

catch(runtime_error& e) {

означает, что мы хотим передать исключение по ссылке. Пожалуйста, пока рассматривайте это выражение просто как техническую подробность. В разделах 8.5.4–8.5.6 мы объясним, что означает передача сущности по ссылке.

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

Исключение out_of_range отличается от исключения runtime_error, поэтому перехват исключения runtime_error не приводит к обработке ошибок out_of_range, которые могут возникнуть при неправильном использовании класса vector или других контейнерных типов из стандартной библиотеки. Однако и out_of_range, и runtime_error являются исключениями, поэтому для работы с ними необходимо предусмотреть перехват объекта класса exception.

int main()
try {
  // наша программа
  return 0; // 0 означает успех
}
catch (exception& e) {
  cerr << "error: " << e.what() << '\n';
  keep_window_open();
  return 1; // 1 означает сбой
}
catch (...) {
  cerr << "Ой: неизвестное исключение !\n";
  keep_window_open();
  return 2; // 2 означает сбой
}

Здесь, для того чтобы перехватить все исключения, мы добавили инструкцию catch(...).

Когда исключения обоих типов (out_of_range и runtime_error) рассматриваются как разновидности одного и того же типа exception, говорят, что тип exception является базовым типом (супертипом) для них обоих. Этот исключительно полезный и мощный механизм будет описан в главах 13–16.

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

При использовании функции error() для описания возникшей проблемы часто необходимо передать две порции информации. В данном случае эти две порции просто объединяются в одну строку. Этот прием настолько широко распространен, что мы решили представить его в виде второго варианта функции error().

void error(string s1, string s2)
{
  throw runtime_error(s1+s2);
}

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

Обратите внимание на то, что использование функции error() не зависит от количества ее предыдущих вызовов: функция error() всегда находит ближайший раздел catch, предусмотренный для перехвата исключения runtime_error (обычно один из них размещается в функции main()). Примеры использования исключений и функции error() приведены в разделах 7.3. и 7.7. Если исключение осталось неперехваченным, то система выдаст сообщение об ошибке (неперехваченное исключение).

ПОПРОБУЙТЕ

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

5.6.4. Суживающие преобразования

В разделе 3.9.2 продемонстрирована ужасная ошибка: когда мы присвоили переменной слишком большое значение, оно было просто усечено. Рассмотрим пример.

int x = 2.9;
char c = 1066;

 Здесь x будет равно 2, а не 2.9, поскольку переменная x имеет тип int, а такие числа не могут иметь дробных частей. Аналогично, если используется обычный набор символов ASCII, то переменная c будет равна 42 (что соответствует символу *), а не 1066, поскольку переменные типа char не могут принимать такие большие значения.

В разделе 3.9.2 показано, как защититься от такого сужения путем проверки. С помощью исключений (и шаблонов; см. раздел 19.3) можно написать функцию, проверяющую и генерирующую исключение runtime_exception, если присваивание или инициализация может привести к изменению значения. Рассмотрим пример.

int x1 = narrow_cast(2.9);    // генерирует исключение
int x2 = narrow_cast(2.0);    // OK
char c1 = narrow_cast(1066); // генерирует исключение
char c2 = narrow_cast(85);   // OK

Угловые скобки, <...>, означают то же самое, что и в выражении vector. Они используются, когда для выражения идеи возникает необходимость указать тип, а не значение. Аргументы, стоящие в угловых скобках, называют шаблонными (template arguments). Если необходимо преобразовать значение и мы не уверены, что оно поместится, то можно использовать тип narrow_cast, определенный в заголовочном файле std_lib_facilities.h и реализованный с помощью функции error(). Слово cast[7] означает приведение типа и отражает роль этой операции в ситуации, когда что-то “сломалось” (по аналогии с гипсовой повязкой на сломанной ноге). Обратите внимание на то, что приведение типа не изменяет операнд, а создает новое значение, имеющее тип, указанный в угловых скобках и соответствующий операнду.

5.7. Логические ошибки

После устранения ошибок, выявленных компилятором и редактором связей, программу выполняют. Как правило, после этого программа либо ничего не выдает на печать, либо выводит неправильные результаты. Это может происходить по многим причинам. Возможно, вы просто неправильно поняли логику программы; написали не то, что намеревались; сделали глупую ошибку в какой-нибудь инструкции if или что-нибудь еще. Логические ошибки обычно труднее всего находить и исправлять, поскольку на этой стадии компьютер делает только то, что вы сами ему приказали. Теперь ваша задача выяснить, почему он делает не то, что вы хотели. В принципе компьютер — это очень быстро действующий идиот. Он просто покорно делает в точности то, что вы ему сказали.

Попробуем проиллюстрировать сказанное на простом примере. Рассмотрим программу-код для поиска минимальной, максимальной и средней температуры.

int main()
{
  vector temps; // температуры
  double temp = 0;
  double sum = 0;
  double high_temp = 0;
  double low_temp = 0;
  while (cin>>temp) // считываем и записываем в вектор temps
    temps.push_back(temp);
  for (int i = 0; i
  {
    if(temps[i] > high_temp) high_temp = temps[i]; // находим
 максимум
    if(temps[i] < low_temp) low_temp = temps[i];   // находим
 минимум
    sum += temps[i]; // вычисляем сумму
  }
  cout << "Максимальная температура: " << high_temp<< endl;
  cout << "Минимальная температура: " << low_temp << endl;
  cout << "Средняя температура:" << sum/temps.size() << endl;
}

Мы проверили эту программу, введя почасовые данные о температуре в центре Люббока, штат Техас (Lubbock, Texas) 16 февраля 2005 года (в штате Техас по-прежнему используется шкала Фаренгейта).

–16.5, –23.2, –24.0, –25.7, –26.1, –18.6, –9.7, –2.4,
7.5, 12.6, 23.8, 25.3, 28.0, 34.8, 36.7, 41.5,
40.3, 42.6, 39.7, 35.4, 12.6, 6.5, –3.7, –14.3

Результаты оказались следующими:

Максимальная температура: 42.6
Минимальная температура: –26.1
Средняя температура: 9.3

Наивный программист может прийти к выводу, что программа работает просто отлично. Безответственный программист продаст ее заказчику. Благоразумный программист проверит программу еще раз. Для этого мы ввели данные, полученные 23 июля 2005 года.

76.5, 73.5, 71.0, 73.6, 70.1, 73.5, 77.6, 85.3,
88.5, 91.7, 95.9, 99.2, 98.2, 100.6, 106.3, 112.4,
110.2, 103.6, 94.9, 91.7, 88.4, 85.2, 85.4, 87.7

На этот раз результаты таковы:

Максимальная температура: 112.4
Минимальная температура: 0.0
Средняя температура: 89.2

Ой, что-то не так. Крепкий мороз (0,0°F соответствует примерно 18°C) в Люббоке в июле — это же просто конец света! Вы видите ошибку? Поскольку переменная low_temp была инициализирована значением 0.0, она останется равной нулю, если все значения температуры окажутся отрицательными.

ПОПРОБУЙТЕ

Выполните эту программу. Убедитесь, что она действительно выдает такие результаты. Попробуйте ее “сломать” (т.е. вынудить выдать неправильные результаты), введя другой набор данных. Сколько данных вам для этого может потребоваться?

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

Такие ошибки типичны; они не создают никаких проблем при компиляции и не приводят к неправильным ответам при разумных условиях. Однако мы забыли указать, что означают разумные условия. Вот как должна выглядеть исправленная программа.

int main()
{
  double temp = 0;
  double sum = 0;
  double high_temp = –1000; // инициализация невозможно низким
 значением
  double low_temp = 1000;   // инициализация невозможно высоким
 значением
  int no_of_temps = 0;
  while (cin>>temp) { // считываем температуру
    ++no_of_temps;    // подсчитываем количество данных
    sum += temp;      // вычисляем сумму
    if (temp > high_temp) high_temp = temp; // находим максимум
    if (temp < low_temp) low_temp = temp;   // находим минимум
  }
  cout << "Максимальная температура: " << high_temp<< endl;
  cout << "Минимальная температура: " << low_temp << endl;
  cout << "Средняя температура:" << sum/temps.size() << endl;
}

Эта программа работает? Почему вы уверены в этом? Вы сможете дать точное определение слова “работает”? Откуда взялись числа 1000 и –1000. Помните о “магических” константах (см. раздел 5.5.1). Указывать числа 1000 и 1000 как литеральные константы в тексте программы — плохой стиль, но может быть, и эти числа неверны? Существуют ли места, где температура опускается ниже —1000°F (–573°C)? Существуют ли места, где температура поднимается выше 1000°F (538°C)?

ПОПРОБУЙТЕ

Просмотрите программу. Используя достоверные источники информации, введите разумные значения для констант min_temp (минимальная температура) и max_temp (максимальная температура). Эти значения определят пределы применимости вашей программы.

5.8. Оценка

Представьте себе, что вы написали простую программу, например, вычисляющую площадь шестиугольника. Вы запустили ее и получили, что площадь равна –34.56. Очевидно, что ответ неверен. Почему? Потому что ни одна фигура не может иметь отрицательную площадь. Итак, вы исправляете ошибку и получаете ответ 21.65685. Этот результат правильный? Ответить на этот вопрос труднее, потому что мы обычно не помним формулу для вычисления площади шестиугольников. Итак, чтобы не опозориться перед пользователями и не поставить им программу, выдающую глупые результаты, необходимо проверить, что ответ правильный. В данном случае это просто. Шестиугольник похож на квадрат. Набросав на бумаге рисунок, легко убедиться, что площадь шестиугольника близка к площади квадрата 3×3. Площадь этого квадрата равна 9. Итак, ответ 21.65685 не может быть правильным! Переделаем программу и получим ответ 10.3923. Это уже похоже на правду!

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

1. Является ли данный ответ разумным для данной задачи?

Можно даже задать более общий (и более трудный) вопрос.

2. Как распознать разумный результат?

Обратите внимание на то, что мы не спрашиваем: “Каков точный ответ?” или “Каков правильный ответ?” Этот ответ нам даст сама программа. Нам лишь хочется, чтобы ответ не был глупым. Только в том случае, если ответ является разумным, имеет смысл продолжать работать над программой.

Оценка — это замечательное искусство, сочетающее в себе здравый смысл и очень простую арифметику. Некоторые люди легко выполняют оценку умозрительно, но мы предпочитаем “рисовать каракули на обратной стороне конверта”, поскольку в противном случае легко сделать ошибку. Итак, здесь мы называем оценкой неформальный набор приемов, или прикидку (guesstimation), сочетающую в себе интуитивную догадку и примерную оценку.

ПОПРОБУЙТЕ

Длины сторон нашего правильного шестиугольника равны 2 см. Получили ли мы правильный ответ? Просто выполните прикидочные вычисления. Возьмите лист бумаги и набросайте эскиз. Не считайте это занятием ниже своего достоинства. Многие знаменитые ученые восхищали людей своими способностями получать примерный ответ с помощью карандаша и клочка бумаги (или салфетки). Эта способность — на самом деле простая привычка — поможет сэкономить массу времени и избежать ошибок.

Часто оценка связана с предварительным анализом данных, необходимых для вычисления, но не имеющихся в наличии. Представьте, что вы протестировали программу, оценивающую время путешествия из одного города в другой. Правдоподобно ли, что из Нью-Йорка в Денвер можно доехать на автомобиле за 15 часов 33 минуты? А из Лондона в Ниццу? Почему да и почему нет? На каких данных основана ваша догадка об ответах на эти вопросы? Часто на помощь приходит быстрый поиск в веб. Например, 2000 миль — это вполне правдоподобная оценка расстояния между Нью-Йорком и Денвером. По этой причине было бы трудно (да и не законно) поддерживать среднюю скорость, равную 130 миль/ч, чтобы добраться из Нью-Йорка в Денвер за 15 часов (15*130 ненамного меньше 2000). Можете проверить сами: мы переоценили и расстояние, и среднюю скорость, но наша оценка правдоподобности ответа вполне обоснована.

ПОПРОБУЙТЕ

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

5.9. Отладка

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

Итак, написав определенную программу, вы должны найти и удалить ошибки. Этот процесс обычно называют отладкой (debugging), а ошибки — жучками (bugs). Иногда говорят, что термин жучок возник в те времена, когда аппаратное обеспечение выходило из строя из-за насекомых, случайно заблудившихся среди электронных ламп и реле, заполнявших комнаты. Иногда считают, что этот термин изобрела Грейс Мюррей Хоппер (Grace Murray Hopper), создатель языка программирования COBOL (см. раздел 22.2.2.2). Кто бы ни придумал этот термин пятьдесят лет назад, ошибки в программах неизбежны и повсеместны. Их поиск и устранение называют отладкой (debugging).

Отладка выглядит примерно так.

1. Компилируем программу.

2. Редактируем связи.

3. Выполняем программу.

Обычно эта последовательность операций выполняется снова и снова: для действительно крупных программ этот процесс повторяется сотни и тысячи раз год за годом. Каждый раз что-то работает не так, как ожидалось, и приходится исправлять какую-то ошибку. Я считаю отладку наиболее утомительной и затратной по времени частью программирования и потратил много времени на то, чтобы минимизировать количество времени, затрачиваемого на отладку. Другие считают, что отладка — это захватывающее занятие, суть программирования, которое затягивает, как видеоигры, и удерживает программиста у компьютера многие дни и ночи (я могу засвидетельствовать это по собственному опыту).

 Приведем пример, как не надо проводить отладку.

while (программа не будет выглядеть работоспособной) { // псевдокод
  Бегло просматриваем программу в поисках странностей
  Изменяем их так, чтобы программа выглядела лучше
}

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

Основной вопрос отладки звучит так:

Как понять, что программа действительно работает правильно?

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

5.9.1. Практические советы по отладке

 Подумайте об отладке, прежде чем напишете первую строку своей программы. Когда написано много строк, уже слишком поздно пытаться упростить отладку. Решите, как сообщать об ошибках. По умолчанию в этой книге принят следующий принцип: “Использовать функцию error() и перехватывать исключение в функции main()”.

 Старайтесь, чтобы программу было легко читать.

• Хорошо комментируйте свою программу. Это не значит просто: “Добавьте много комментариев”. Вы не можете сформулировать смысл операции на естественном языке лучше, чем на языке программирования. В комментариях следует ясно и коротко указать то, что невозможно выразить в коде.

• Название программы.

• Цель программы.

• Кто написал программу и зачем.

• Номера версий.

• Какие фрагменты кода могут вызвать сложности.

• Основные идеи.

• Как организован код.

• Какие предположения сделаны относительно вводных данных.

• Каких фрагментов кода пока не хватает и какие варианты еще не обработаны.

• Используйте осмысленные имена.

• Это не значит: “Используйте длинные имена”.

• Используйте логичную схему кода.

• Ваша интегрированная среда программирования может помочь, но она не может сделать за вас всю работу.

• Воспользуйтесь стилем, принятым в книге.

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

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

• Избегайте сложных выражений.

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

• Используйте, где только можно, библиотечные функции, а не собственный код.

• Библиотеки, как правило, лучше продуманы и протестированы, чем ваши собственные программы.

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

Скомпилируйте программу. Разумеется, для этого понадобится компилятор. Его сообщения обычно весьма полезны, даже если мы хотели бы лучшего, и если вы не профессионал, то должны считать, что компьютер всегда прав. Если же вы реальный эксперт, то закройте книгу — она написана не для вас. Иногда программисту кажется, что правила компилятора слишком тупые и слишком строгие (как правило, это не так), и многие вещи можно было бы сделать проще (как бы не так). Однако, как говорится, “свой инструмент проклинает только плохой мастер”. Хороший мастер знает сильные и слабые стороны своего инструмента и соответственно его настраивает. Рассмотрим наиболее распространенные ошибки компиляции.

• Закрыта ли кавычка строки литералов?

cout << "Привет, << name << '\n'; // Ой!

• Закрыта ли кавычка отдельного литерала?

cout << "Привет, " << name << '\n; // Ой!

• Закрыта ли фигурная скобка блока?

int f(int a)
{
  if (a>0) {/* что-то делаем */ else {/* делаем что-то 
другое */}
} // Ой!

• Совпадает ли количество открывающих и закрывающих скобок?

if (a<=0 // Ой!
x = f(y);

Компилятор обычно сообщает об этих ошибках “поздно”; он просто не знает, что вы имели в виду, когда забыли поставить закрывающую скобку после нуля.

• Каждое ли имя объявлено?

• Включены ли все необходимые заголовочные файлы (например, #include "std_lib_facilities.h")?

• Объявлено ли каждое имя до его использования?

• Правильно ли набраны все имена?

int count; /* ... */ ++Count; // Ой!
char ch;   /* ... */ Cin>>c;  // Ой-ой!

• Поставлена ли точка с запятой после каждой инструкции?

x = sqrt(y)+2 // Ой!
z = x+3;

В упражнениях мы привели еще больше примеров таких ошибок. Кроме того, помните о классификации ошибок, указанной в разделе 5.2.

После того как программа скомпилирована, а ее связи отредактированы, наступает самый трудный этап, на котором необходимо понять, почему программа работает не так, как вы предполагали. Вы смотрите на результаты и пытаетесь понять, как ваша программа могла их вычислить. На самом деле чаще программисты смотрят на пустой экран и гадают, почему их программа ничего не вывела. Обычная проблема с консолью Windows заключается в том, что она исчезает, не дав вам шанса увидеть, что было выведено на экран (если что-то все-таки было выведено). Одно из решений этой проблемы — вызвать функцию keep_window_open() из заголовочного файла std_lib_facilities.h в конце функции main(). В таком случае программа попросит вас ввести что-нибудь перед выходом, и вы сможете просмотреть результаты ее работы до того, как окно закроется. В поисках ошибок тщательно проверьте инструкцию за инструкцией, начиная с того места, до которого, по вашему мнению, программа работала правильно. Встаньте на место компьютера, выполняющего вашу программу. Соответствует ли вывод вашим ожиданиям? Разумеется, нет, иначе вы не занимались бы отладкой.

• Часто, когда программист не видит проблемы, причина заключается в том, что вы видите не действительное, а желаемое. Рассмотрим пример.

for (int i = 0; i<=max; ++j) { // Ой! (Дважды)
  for (int i=0; 0
    cout << "v[" << i << "]==" << v[i] << '\n';

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

• Часто, когда вы не видите проблемы, причина заключается в том, что между точкой, где программа еще работала правильно, и следующей точкой, где программа выдала неверный ответ, содержится слишком много инструкций (или выводится слишком мало информации). Большинство интегрированных сред программирования допускают пошаговую отладку программ. В конце концов, вы научитесь пользоваться этими возможностями, но при отладке простых программ достаточно расставить в нескольких местах дополнительные инструкции вывода (с помощью потока cerr). Рассмотрим пример.

int my_fct(int a, double d)
{
  int res = 0;
  cerr << "my_fct(" << a << "," << d << ")\n";
  // ...какой-то код...
  cerr << "my_fct() возвращает " << res << '\n';
  return res;
}

• Вставьте инструкции для проверки инвариантов (т.е. условий, которые всегда должны выполняться; см. раздел 9.4.3) в подозрительные разделы.

Рассмотрим пример.

int my_complicated_function(int a, int b, int c)
// Аргументы являются положительными и a < b < c
{
  if (!(0
    error("Неверные аргументы функции mcf");
  // ...
}

• Если все сказанное не привело к успеху, вставьте инварианты в разделы программы, которые вы считаете правильными. Весьма вероятно, что вы найдете ошибку. Инструкция для проверки инвариантов называется assert.

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

5.10. Пред- и постусловия

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

int my_complicated_function(int a, int b, int c)
// Аргументы являются положительными и a < b < c
{

  if (!(0

    error("Неверные аргументы функции mcf");
  // ...
}

Во-первых, в комментарии утверждается, какие аргументы ожидает функция, а затем происходит проверка этого условия (и генерирование исключения, если это условие нарушается). Это правильная стратегия. Требования, которые функция предъявляет к своим аргументам, часто называют предусловиями (pre-condition): они должны выполняться, чтобы функция работала правильно. Вопрос заключается в том, что делать, если предусловия нарушаются. У нас есть две возможности.

1. Игнорировать это (надеясь или предполагая, что все вызывающие функции передают правильные аргументы).

2. Проверить их (и каким-то образом сообщить об ошибке).

С этой точки зрения типы аргументов — это лишь способ проверки простейших предусловий на этапе компиляции. Рассмотрим пример.

int x = my_complicated_function(1, 2, "horsefeathers");

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

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

• Никто не может передать неправильные аргументы.

• Проверка слишком сильно замедлит выполнение программы.

• Проверка является слишком сложной.

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

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

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

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

int my_complicated_function(int a, int b, int c)
// Аргументы являются положительными и a < b < c
{

if (!(0

  error("Неверные аргументы функции mcf");
  // ...
}

сэкономит ваше время и силы по сравнению с более простым вариантом:

int my_complicated_function(int a, int b, int c)
{
  // ...
}

5.10.1. Постусловия

Формулировка предусловий позволяет улучшить структуру программы и перехватить неправильное использование функций на ранних этапах программирования. Можно ли использовать эту идею где-нибудь еще? Да, на ум сразу приходит оператор return! Помимо всего прочего, следует указать, что именно функция будет возвращать; иначе говоря, если мы возвращаем из функции какое-то значение, то всегда обещаем вернуть что-то конкретное (а как иначе вызывающая функция будет знать, чего ей ждать?).

Вернемся к нашей функции, вычисляющей площадь прямоугольника (см. раздел 5.6.1).

// Вычисляет площадь прямоугольника;
// если аргументы неправильные, генерирует исключение Bad_area
int area(int length, int width)
{
  if (length<=0 || width <=0) throw Bad_area();
    return length*width;
}

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

int area(int length, int width)
// Вычисляет площадь прямоугольника;
// предусловия: аргументы length и width являются положительными
// постусловия: возвращает положительное значение, являющееся
// площадью
{
  if (length<=0 || width <=0) error("area() pre-condition");
  int a = length*width;
  if (a<=0) error("area() post-condition");
  return a;
}

Мы не можем проверить выполнение всех постусловий, но можем проверить их часть, убедившись, что возвращаемое число является положительным.

ПОПРОБУЙТЕ

Найдите пару значений, при которых предусловие выполняется, а постусловие — нет.

Пред- и постусловия обеспечивают проверку логичности кода. Они тесно связаны с понятиями инвариантов (раздел 9.4.3), корректности (разделы 4.2 и 5.2), а также с тестированием (глава 26).

5.11. Тестирование

Как определить, когда следует остановить отладку? Ясно, что отладка должна идти до тех пор, пока не будут выявлены все ошибки, — или нам так покажется. А как узнать, что мы нашли последнюю ошибку? Мы не знаем. Последняя ошибка — это шутка программистов. Такой ошибки не существует. В большой программе никогда невозможно найти последнюю ошибку.

 Кроме отладки, нам необходим систематический подход к поиску ошибок. Он называется тестированием (testing) и рассматривается в разделе 7.3, упражнениях к главе 10 и в главе 26. В принципе тестирование — это выполнение программы с большим и систематически подобранным множеством входных данных и сравнение результатов с ожидаемыми. Выполнение программы с заданным множеством входных данных называют тестовым вариантом (test case). Для реальных программ могут потребоваться миллионы тестовых вариантов. Тестирование не может быть ручным, когда программист набирает варианты тест за тестом, поэтому в последующих главах мы рассмотрим инструменты, необходимые для правильного тестирования.

 Тем временем напомним, что тестирование основано на убеждении, что поиск ошибок выполняется правильно. Рассмотрим пример.

Точка зрения 1. Я умнее любой программы! Я могу взломать код @#$%^!

Точка зрения 2. Я вылизывал эту программу две недели. Она идеальна!

Как вы думаете, кто из этих двух программистов найдет больше ошибок? Разумеется, наилучшим вариантом является опытный программист, придерживающийся первой точки зрения и спокойно, хладнокровно, терпеливо и систематически работающий над ошибками. Хорошие тестировщики на вес золота!

Мы стараемся систематически выбирать тестовые варианты и всегда проверять правильные и неправильные входные данные. Первый пример будет приведен в разделе 7.3.

Задание

Ниже приведены двадцать пять фрагментов кода. Каждый из них должен быть впоследствии вставлен в определенное место программы.

#include "std_lib_facilities.h"
int main()
try {
<< здесь будет ваш код >>
  keep_window_open();
  return 0;
}
catch (exception& e) {
  cerr << "error: " << e.what() << '\n';
  keep_window_open();
  return 1;
}
catch (…) {
  cerr << "Ой: неизвестное исключение !\n";
  keep_window_open();
  return 2;
}

В некоторых из них есть ошибки, а в некоторых — нет. Ваша задача — найти и устранить все ошибки. Устранив эти ошибки, скомпилируйте программу, выполните ее и выведите на экран слово “Success!”. Даже если вы считаете, что нашли все ошибки, вставьте в программу исходный (неисправленный) вариант и протестируйте его; может быть, ваша догадка об ошибке была неверной или во фрагменте их несколько. Кроме того, одной из целей этого задания является анализ реакции компилятора на разные виды ошибок. Не набирайте эти фрагменты двадцать пять раз — для этого существует прием “copy–paste”. Не устраняйте проблемы, просто удаляя инструкции; исправляйте их, изменяя, добавляя или удаляя символы.

1. cout << "Success!\n";
2. cout << "Success!\n;
3. cout << "Success" << !\n"
4. cout << success << endl;
5. string res = 7; vector v(10); v[5] = res; cout << "Success!\n";
6. vector v(10); v(5) = 7; if (v(5)!=7) cout << "Success!\n";
7. if (cond) cout << "Success!\n"; else cout << "Fail!\n";
8. bool c = false; if (c) cout << "Success!\n"; else cout << "Fail!\n";
9. string s = "ape"; boo c = "fool"
10. string s = "ape"; if (s=="fool") cout << "Success!\n";
11. string s = "ape"; if (s=="fool") cout < "Success!\n";
12. string s = "ape"; if (s+"fool") cout < "Success!\n";
13. vector v(5); for (int i=0; 0
    cout << "Success!\n";
14. vector v(5); for (int i=0; i<=v.size(); ++i);
    cout << "Success!\n";
15. string s = "Success!\n"; for (int i=0; i<6; ++i) cout << s[i];
16. if (true) then cout << "Success!\n"; else cout << "Fail!\n";
17. int x = 2000; char c = x; if (c==2000) cout << "Success!\n";
18. string s = "Success!\n"; for (int i=0; i<10; ++i) cout << s[i];
19. vector v(5); for (int i=0; i<=v.size(); ++i);
    cout << "Success!\n";
20. int i=0; int j = 9; while (i<10) ++j;
    if (j
21. int x = 2; double d = 5/(x–2); if (d==2*x+0.5) cout << "Success!\n";
22. string s = "Success!\n"; for (int i=0; i<=10; 
++i) cout << s[i];
23. int i=0; while (i<10) ++j; if (j
24. int x = 4; double d = 5/(x–2); if (d=2*x+0.5) cout << "Success!\n";
25. cin << "Success!\n";

Контрольные вопросы

1. Назовите четыре основных вида ошибок и кратко опишите их.

2. Какие виды ошибок в студенческих программах можно проигнорировать?

3. Что должен гарантировать любой законченный проект?

4. Перечислите три подхода к исключению ошибок в программе и разработке правильного программного обеспечения.

5. Почему мы ненавидим отладку?

6. Что такое синтаксическая ошибка? Приведите пять примеров.

7. Что такое ошибка типа? Приведите пять примеров.

8. Что такое ошибка этапа редактирования связей? Приведите три примера.

9. Что такое логическая ошибка? Приведите три примера.

10. Перечислите четыре источника потенциальных ошибок, рассмотренных в тексте.

11. Как распознать разумные результаты? Какие методы используются для ответа на этот вопрос?

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

13. Почему использование исключений лучше, чем возврат признака ошибки?

14. Как выполнить тестирование при последовательном вводе данных?

15. Опишите процесс генерирования и перехвата исключений.

16. Почему выражение v[v.size()] относительно вектора v порождает ошибку диапазона? Каким может быть результат такого вызова?

17. Дайте определение пред- и постусловия; приведите пример (который отличается от функции area() из этой главы), предпочтительно использовать вычисления, требующие применения цикла.

18. В каких ситуациях можно не проверять предусловие?

19. В каких ситуациях можно не проверять постусловие?

20. Назовите этапы отладки.

21. Чем комментарии могут помочь при отладке?

22. Чем тестирование отличается от отладки?

Термины

Упражнения

1. Выполните задание из раздела ПОПРОБУЙТЕ, если вы его еще не сделали.

2. Следующая программа вводит температуру по шкале Цельсия и преобразует ее в шкалу Кельвина. Этот код содержит много ошибок. Найдите ошибки, перечислите их и исправьте программу.

double ctok(double c) // преобразует шкалу Цельсия в шкалу Кельвина
{
  int k = c + 273.15;
  return int
}

int main()
{
  double c = 0;         // объявляем переменную для ввода
  cin >> d;             // вводим температуру в переменную ввода
  double k = ctok("c"); // преобразуем температуру
  Cout << k << endl;    // выводим температуру на печать
}

3. Самой низкой температурой является абсолютный нуль, т.е. –273,15°C, или 0 K. Даже после исправления приведенная выше программа выводит неверные результаты для температуры ниже абсолютного нуля. Поместите в функцию main() проверку, которая выводит сообщение об ошибке, если температура ниже –273,15°C.

4. Повторите упр. 3, но на этот раз ошибку обработайте в функции ctok().

5. Измените программу так, чтобы она преобразовывала шкалу Кельвина в шкалу Цельсия.

6. Напишите программу, преобразовывающую шкалу Цельсия в шкалу Фаренгейта и наоборот (по формуле из раздела 4.3.3). Для того чтобы распознать разумные результаты, используйте оценку из раздела 5.8.

7. Квадратное уравнение имеет вид

Для решения этого уравнения используется формула

Тем не менее есть одна проблема: если b²–4ac меньше нуля, возникнет ошибка. Напишите программу, вычисляющую решение квадратного уравнения. Напишите функцию, которая выводит на печать все корни квадратного уравнения при заданных коэффициентах a, b и c. Вызовите эту функцию из модуля main() и перехватите исключение, если возникнет ошибка. Если программа выявит, что уравнение не имеет действительных корней, она должна вывести на печать соответствующее сообщение. Как распознать разумные результаты? Можете ли вы проверить, что они являются правильными?

8. Напишите программу, считывающую ряд чисел и записывающую их в vector. После того как пользователь введет все числа, он может попытаться определить, сколько чисел он ввел, чтобы найти их сумму. Выведите ответ N, равный количеству элементов в векторе. Например:

“Пожалуйста, введите несколько чисел (для прекращения ввода нажмите клавишу <|>):”

12 23 13 24 15 “Пожалуйста, введите количество чисел, которые хотите просуммировать:”

“Сумма первых 3 чисел: 12 , 23 и 13 равна 48.”

9. Измените программу из упр. 8, чтобы она использовала тип double вместо int. Кроме того, создайте вектор действительных чисел, содержащий N–1 разностей между соседними величинами, и выведите этот вектор на печать.

10. Напишите программу, вычисляющую начальный отрезок последовательности Фибоначчи, т.е. последовательности, начинающиеся с чисел 1 1 2 3 5 8 13 21 34. Каждое число в этой последовательности равно сумме двух предыдущих. Найдите последнее число Фибоначчи, которое можно записать в переменную типа int.

11. Реализуйте простую игру на угадывание “Быки и коровы”. Программа должна хранить вектор из четырех чисел в диапазоне от 0 до 9, а пользователь должен угадать загаданное число. Допустим, программа загадала число 1234, а пользователь назвал число 1359; программа должна ответить “1 бык и 1 корова”, поскольку пользователь угадал одну правильную цифру (1) на правильной позиции (бык) и одну правильную цифру (3) на неправильной позиции (корова). Угадывание продолжается, пока пользователь не получит четырех быков, т.е. не угадает четыре правильные цифры на четырех правильных позициях.

12. Эта программа довольно сложная, поскольку ответы трудно кодировать. Создайте вариант, в котором игрок может играть постоянно (без остановки и повторного запуска) и в каждой новой игре генерируются новые четыре цифры. Четыре случайные цифры можно сгенерировать с помощью четырех вызовов генератора случайных целых чисел randint(10) из заголовочного файла std_lib_facilities.h. Обратите внимание на то, что при постоянном выполнении программы вы каждый раз при новом сеансе будете получать одинаковые последовательности, состоящие из четырех цифр. Для того чтобы избежать этого, предложите пользователю ввести любое число и вызовите функцию srand(n), где n — число, введенное пользователем до вызова функции randint(10). Такое число n называется начальным значением (seed), причем разные начальные значения приводят к разным последовательностям случайных чисел.

13. Введите пары (день недели, значение) из стандартного потока ввода. Например:

Tuesday 23 Friday 56 Tuesday –3 Thursday 99

Запишите все значения для каждого дня недели в вектор vector. Запишите значения семи дней недели в отдельный вектор. Напечатайте сумму чисел для каждого из векторов. Неправильный день недели, например Funday, можно игнорировать, но синонимы допускаются, например Mon и monday. Выведите на печать количество отвергнутых чисел.

Послесловие

Не считаете ли вы, что мы придаем ошибкам слишком большое значение? Новички могут подумать именно так. Очевидная и естественная реакция такова: “Все не может быть настолько плохо!” Именно так, все именно настолько плохо. Лучшие умы планеты поражаются и пасуют перед сложностью создания правильных программ. По нашему опыту, хорошие математики, как правило, недооценивают проблему ошибок, но всем ясно, что программ, которые с первого раза выполняются правильно, очень немного. Мы вас предупредили! К счастью, за пятьдесят лет мы научились организовывать код так, чтобы минимизировать количество проблем, и разработали методы поиска ошибок, которые, несмотря на все наши усилия, неизбежны. Методы и примеры, описанные в этой главе, являются хорошей отправной точкой.

Глава 6. Создание программ