Кирилл Сурков
Александр Вальвачев, Дмитрий Сурков, Юрий Четырько
дата публикации 17-02-2006 04:23

---

Версия для печати

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

4.1. Ошибки и исключительные ситуации

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

Хорошая программа должна справляться со своими ошибками и работать дальше, не зацикливаясь и не зависая ни при каких обстоятельствах. Для обработки ошибок можно, конечно, пытаться использовать структуры вида if then Exit. Однако в этом случае ваш стройный и красивый алгоритм решения основной задачи обрастет уродливыми проверками так, что через неделю вы сами в нем не разберетесь. Из этой почти тупиковой ситуации среда Delphi предлагает простой и элегантный выход — механизм обработки исключительных ситуаций.

Исключительная ситуация (exception) — это прерывание нормального хода работы программы из-за невозможности правильно выполнить последующие действия.

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

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

Механизм обработки исключительных ситуаций довольно сложен в своей реализации, но для программиста он прост и прозрачен. Для его использования в язык Delphi введены специальные конструкции try...except...end, try...finally...end и оператор raise, рассмотренные в этой главе.

4.2. Классы исключительных ситуаций

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

Классы исключительных ситуаций образуют иерархию, корнем которой является класс Exception. Класс Exception описывает самый общий тип исключительных ситуаций, а его наследники — конкретные виды таких ситуаций (таблица 4.1). Например, класс EOutOfMemory порожден от Exception и описывает ситуацию, когда свободная оперативная память исчерпана.

В следующей таблице приведены стандартные классы исключительных ситуаций, объявленные в модуле SysUtils. Они покрывают практически весь спектр возможных ошибок. Если их все-таки окажется недостаточно, вы можете объявить новые классы исключительных ситуаций, порожденные от класса Exception или его наследников.

Таблица 4.1. Классы исключительных ситуаций

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

type EMathError = class(Exception); EInvalidOp = class(EMathError); EZeroDivide = class(EMathError); EOverflow = class(EMathError); EUnderflow = class(EMathError);

Класс исключительных ситуаций EMathError является базовым для классов EInvalidOp, EZeroDivide, EOverflow и EUnderflow, поэтому, обрабатывая исключительные ситуации класса EMathError, вы будете обрабатывать все ошибки вещественной математики, включая EInvalidOp, EZeroDivide, EOverflow и EUnderflow.

Нетрудно заметить, что имена классов исключений начинаются с буквы E (от слова Exception). Этого правила полезно придерживаться при объявлении собственных классов исключений, например:

type EMyException = class(Exception) MyErrorCode: Integer; end;

Как описываются классы исключительных ситуаций понятно, рассмотрим теперь, как такие ситуации обрабатываются.

4.3. Обработка исключительных ситуаций

4.3.1. Создание исключительной ситуации

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

raise EOutOfMemory.Create('Маловато памяти');

Данный оператор создает объект класса EOutOfMemory (класс ошибок исчерпания памяти) и прерывает нормальное выполнение программы. Вызывающие подпрограммы могут эту исключительную ситуацию перехватить и обработать. Для этого в них организуется так называемый защищенный блок:

try // защищаемые от ошибок операторы except // операторы обработки исключительной ситуации end;

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

Рисунок 4.1. Логика работы оператора try…except…end

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

try // защищаемые операторы try // защищаемые операторы except // локальная обработка исключительных ситуаций end; // защищаемые операторы except // глобальная обработка исключительных ситуаций end;

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

4.3.2. Распознавание класса исключительной ситуации

Распознавание класса исключительной ситуации выполняется с помощью конструкций

on <класс исключительной ситуации> do <оператор>;

которые записываются в секции обработки исключительной ситуации, например:

try // вычисления с вещественными числами except on EZeroDivide do ... ; // обработка ошибки деления на нуль on EMathError do ... ; // обработка других ошибок вещественной математики end;

Поиск соответствующего обработчика выполняется последовательно до тех пор, пока класс исключительной ситуации не окажется совместимым с классом, указанным в операторе on. Как только обработчик найден, выпоняется оператор, стоящий за словом do и управление передается за секцию except...end. Если исключительная ситуация не относится ни к одному из указанных классов, то управление передается во внешний блок try...except...end и обработчик ищется в нем.

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

На самом высоком уровне программы бывает необходимо перехватывать все исключительные ситуации, чтобы в случае какой-нибудь неучтенной ошибки корректно завершить приложение. Для этого применяется так называемый обработчик по умолчанию (default exception handler). Он записывается в секции except после всех операторов on и начинается ключевым словом else:

try { вычисления с вещественными числами } except on EZeroDivide do { обработка ошибки деления на нуль }; on EMathError do { обработка других ошибок вещественной математики }; else { обработка всех остальных ошибок (обработчик по умолчанию) }; end;

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

4.3.3. Пример обработки исключительной ситуации

В качестве примера обработки исключительной ситуации рассмотрим две функции: StringToCardinal и StringToCardinalDef.

Функция StringToCardinal выполняет преобразование строки в число с типом Cardinal. Если преобразование невозможно, функция создает исключительную ситуацию класса EConvertError.

function StringToCardinal(const S: string): Cardinal; var I: Integer; B: Cardinal; begin Result := 0; B := 1; for I := Length(S) downto 1 do begin if not (S[I] in ['0'..'9']) then raise EConvertError.Create(S + ' is not a valid cardinal value'); Result := Result + B * (Ord(S[I]) - Ord('0')); B := B * 10; end; end;

Функция StringToCardinalDef также выполняет преобразование строки в число с типом Cardinal, но в отличие от функции StringToCardinal она не создает исключительную ситуацию. Вместо этого она позволяет задать значение, которое возвращается в случае неудачной попытки преобразования:

function StringToCardinalDef(const S: string; Default: Cardinal = 0): Cardinal; begin try Result := StringToCardinal(S); except on EConvertError do Result := Default; end; end;

Для преобразования исходной строки в число используется определенная выше функция StringToCardinal. Если при преобразовании возникает исключительная ситуация, то она "поглощается" функцией StringToCardinalDef, которая в этом случае возвращает значение параметра Default. Если происходит какая-нибудь другая ошибка (не EConvertError), то управление передается внешнему блоку обработки исключительных ситуаций, из которого была вызвана функция StringToCardinalDef.

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

4.3.4. Возобновление исключительной ситуации

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

try // вычисления с вещественными числами except on EZeroDivide do begin // частичная обработка ошибки raise; // возобновление исключительной ситуации end; end;

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

4.3.5. Доступ к объекту, описывающему исключительную ситуацию

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

on <идентификатор объекта> : <класс исключительной ситуации> do <оператор>;

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

try // защищаемые операторы except on E: EOutOfMemory do ShowMessage(E.Message); end;

Переменная E — это объект исключительной ситуации, ShowMessage — процедура модуля DIALOGS, отображающая на экране небольшое окно с текстом и кнопкой OK. Свойство Message типа string определено в классе Exception, оно содержит текстовое описание ошибки. Исходное значение для текста сообщения указывается при конструировании объекта исключительной ситуации.

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

4.4. Защита выделенных ресурсов от пропадания

4.4.1. Утечка ресурсов и защита от нее

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

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

// запрос ресурса try // защищаемые операторы, которые используют ресурс finally // освобождение ресурса end;

Особенность этого блока состоит в том, что секция finally...end выполняется всегда независимо от того, происходит исключительная ситуация или нет. Если какой-либо оператор секции try...finally генерирует исключительную ситуацию, то сначала выполняется секция finally...end, называемая секцией завершения (освобождения ресурсов), а затем управление передается внешнему защищенному блоку. Если все защищаемые операторы выполняются без ошибок, то секция завершения тоже работает, но управление передается следующему за ней оператору. Обратите внимание, что секция finally...end не обрабатывает исключительную ситуацию, в ней нет ни средств ее обнаружения, ни средств доступа к объекту исключительной ситуации.

Рисунок 4.1. Логика работы оператора try…except…end

Блок try...finally...end обладает еще одной важной особенностью. Если он помещен в цикл, то вызов из защищенного блока процедуры Break с целью преждевременного выхода из цикла или процедуры Continue с целью перехода на следующую итерацию цикла сначала обеспечивает выполнение секции finally...end, а затем уже выполняется соответствующий переход. Это утверждение справедливо также и для процедуры Exit (выход из подпрограммы).

Как показывает практика, подпрограммы часто распределяют сразу несколько ресурсов и используют их вместе. В таких случаях применяются вложенные блоки try...finally...end:

// распределение первого ресурса try ... // распределение второго ресурса try // использование обоих ресурсов finally // освобождение второго ресурса end; ... finally // освобождение первого ресурса end;

Кроме того, вы успешно можете комбинировать блоки try...finally...end и try...except...end для защиты ресурсов и обработки исключительных ситуаций.

4.5. Итоги

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