Проверка на ошибку на делфи

Июль 26th, 2013 admin

Комплексный контроль за качеством кода

Оформил: DeeCo

Автор: Николай Мазуркин

Оглавление

1. Введение
2. Процедура
   Assert
3. Номера
   строк или уникальные метки ?
4. Категории
   ошибок
5. Тотальный
   контроль
6. Заключение
7. Пример
   модуля с функциями комплексной обработки ошибок
8. Пример
   использования системы комплексного контроля

1. Введение

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

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

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

2. Процедура ASSERT

В Object Pascal введена
специализированная процедура Assert, назначение которой — помощь в отладке
кода и контроле над выполнением программы. Процедура является аналогом
макроса ASSERT, который широко применяется практически во всех программах,
написанных с использованием C и C++ и их библиотек. Синтаксис процедуры
Assert (макрос имеет похожий синтаксис) описан ниже.

procedure Assert(Condition: Boolean; [Msg: string]);

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

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

В языках С и С++ отладочный режим компиляции задается определением
(#define) соответствующей константы, обычно это _DEBUG. В Object Pascal
отладочный режим включается специальной опцией компилятора. Кроме того, в
С и С++ макрос ASSERT — это обычный макрос, ничем не отличающийся от
множества других макросов. Макрос использует переменную компилятора
__LINE__, что позволяет ему определить номер строки, в которой произошло
нарушение проверки. В Object Pascal такой переменной нет, и за реализацию
процедуры Assert полностью отвечает компилятор, что позволяет говорить о
процедуре Assert, как об особенности компилятора и языка Object Pascal, а
не как об обычной процедуре в составе библиотеки VCL.

Процедура Assert обычно применяется в следующих случаях:

• в начале процедуры или функции для проверки правильности переданных
  аргументов;
• в начале процедуры или функции для проверки правильности внутренних
  переменных;
• в конце работы алгоритма для проверки правильности работы алгоритма;
• для проверки правильности выполнения «надежных» функций, то есть тех
  функций, которые всегда должны выполняться успешно всегда, и их
  невыполнение рассматривается как фатальная ошибка программы. Хороший
  пример — функция CloseHandle вызываемая с верным дескриптором.
  Практически, можно не сомневаться в правильности выполнения этой
  функции, однако результат ее выполнения все-таки можно и нужно
  проверить. Подробнее об этом в главе «Категории
  ошибок».

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

procedure AddElement(Elem: TObject; Index: Integer);
begin
  // Ссылка на объект не должна быть пустой
  Assert(Elem <> nil, 'Пустая ссылка.');
  // Индекс должен быть в пределах нормы
  Assert((0 <= Index) and (Index < FCount), 'Неверный индекс');
  // Что-то делаем
  ...
    // Проверяем результат алгоритма
  Assert(Result = 0, 'Ошибка в алгоритме вставки элемента');
end;

Первая процедура проверяет, является ли переданная ссылка на объект
непустой. Вторая процедура проверяет индекс добавляемого элемента на
принадлежность к ограниченному диапазону. Третья процедура проверяет
правильность выполнения алгоритма. Ясно, что при невыполнении хотя бы
одного из этих условий, необходимо считать, что данная процедура
выполнилась неправильно, и дальнейшее правильное выполнение всей программы
не представляется возможным. Ясно также, что, так как данную процедуру
(процедуру AddElement) вызываем только мы (наша программа), такое событие
никогда не должно происходить, в предположении, что алгоритм правилен и
аргументы, передаваемые в функцию, верные. Однако, как известно: «Человек
полагает, а Бог располагает», и при невнимательном программировании в
большом проекте такой тип ошибок становиться основным.

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

В настоящее время (в пятой версии Delphi и несколько более ранних
версиях), процедура Assert генерирует на месте своего вызова исключение
типа EAssertionFailed и дальнейшее следование этого исключения
осуществляется обычным образом — вверх по стеку процедур до ближайшего
обработчика исключений. Исключения от процедуры Assert обрабатываются
таким же образом, как и все другие — объект TApplication ловит все
исключения и показывает их тип и их сообщения на экране. Однако такой
подход трудно считать логичным. Исключения от процедуры Assert коренным
образом отличаются от остальных исключений. Исключения от процедуры Assert
свидетельствуют о серьезных ошибках в логике работы программы и требуют
особого внимания, вплоть до принудительного завершения программы с выводом
особого диагностического сообщения.

Реализация процедуры Assert в Object Pascal полностью возложена на
компилятор (вернее на «приближенный ко двору» модуль system.pas), что
несколько затрудняет изменение логики работы. Возможны три основных
варианта внесения изменений в логику работы.

1. Установка обработчика события TApplication.OnException и обработка в
   нем исключения с типом EAssertionFailed. Данный способ является наиболее
   простым, и менее гибким. Подходит, если все что необходимо — это вывести
   на экран особое сообщение и принудительно завершить программу.
2. Прямая установка обработчика процедуры Assert, путем присвоения
   адреса своей процедуры системной переменной AssertErrorProc. Область
   применения практически та же самая, что и в предыдущем случае. Однако, в
   этом случае, возможны и более сложные манипуляции. Например, можно
   написать обработчик, который не генерирует исключение, а сразу выводит
   сообщение и принудительно завершает программу. Пример такого обработчика
   приведен ниже.

   procedure AssertHandlerMSG(const Msg, Module: string; Line: Integer;
     ErrorAddr: Pointer);
   begin
     // Выводим сообщение
     MessageBox(0,
       PChar(Format('Error "%s" at address 0x%8.8x in file %s, line %d.',
       [Msg, Integer(ErrorAddr), Module, Line])),
       'Error',
       MB_OK
       );
     // Выходим из программы
     ExitProcess(1);
   end;
   ...
   // Настройка ссылки на глобальный обработчик процедуры Assert
   AssertErrorProc := @AssertHandlerMSG;

3. Написание процедуры Assert заново. Самый гибкий и удобный вариант.
   Например, если вас не устраивает стандартный синтаксис процедуры Assert,
   и вы хотите передать в процедуру дополнительные параметры (например, тип
   ошибки, тип генерируемого исключения, код, и т.п.). При этом возникает
   два особых момента связанных с тем фактом, что за процедуру Assert
   отвечает компилятор. Во-первых, вы не сможете управлять включением и
   включением вызовов процедуры Assert в программе через стандартные опции.
   Процедура Assert будет выполняться всегда. Единственное, что вы можете
   сделать — это сразу выйти из процедуры, если режим работы программы не
   отладочный. Во-вторых, в самой процедуре невозможно узнать номер строки,
   в которой произошел вызов процедуры. Тем не менее, обе этих трудности
   преодолимы.

Необходимость включения и выключения вызовов
процедуры Assert, связанных с режимом работы программы является само собой
подразумевающейся. Считается, что выключение вызовов Assert в отлаженной
программе позволяет уменьшить размер программы и увеличить скорость ее
работы. Однако, экономия на размере и увеличение быстродействия являются
весьма малыми (если вы не включаете процедуру Assert в тело каждого
цикла). Происходящее на этом фоне, молчаливое съедание ошибок в программе
ставит под сомнение необходимость отключать вызовы процедуры Assert в
«готовой» программе. То, что вы не нашли ошибок при разработке и отладке
программы вовсе не означает, что там их нет. Ошибки могут появиться у
пользователя программы, например, в условиях, в которых программа не
тестировалась. Как вы о них узнаете, если отключите вызовы Assert?
Конечно, лукавое отключение предупреждений может на время сохранить вашу
репутацию, и пользователь может и не узнать о тех ужасах, которые
происходят в недрах вашей программы. А внезапный безымянный сбой вашей
программы вы можете списать на особенности работы Windows. Однако качества
вашей программе это не прибавит. Честная регистрация всех ошибок намного
улучшит ваши программы.

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

procedure AssertMsg(Condition: Boolean; const Mark: string);
var
  ExceptAddr: Pointer;
begin
  // Если условие выполняется, то выходим
  if Condition then
    Exit;
  // Получаем адрес вызвавшей нас команды Call
  asm
    mov EAX, [EBP+$04]
    mov ExceptAddr, EAX
  end;
  // Возбуждаем исключение в месте вызова этой функции
  raise EFatalExcept.Create('Неожиданная ошибка. ' + #13#13+Mark)at
    ExceptAddr;
end;

3. Номера строк или уникальные метки ?

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

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

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

Существует прекрасный вариант решения этой проблемы. В среде Delphi
нажмите клавиши <CTRL>+<SHIFT>+<G> и вы получите строку
похожую на эту: [‘{19619100-22B0-11D4-ACD0-009027350D25}’]. Это уникальный
идентификатор GUID (Global Unique IDentificator), шестнадцатибайтное
уникальное значение, переведенное в строковый вид с разграничителями и
заключенное в квадратные скобки. Такое значение уникально, оно зависит от
времени и от номера сетевой карты. Если сетевой карты нет, то номер
генерируется программно. По крайней мере, Microsoft утверждает, что такой
номер никогда не повторится. Каждый раз, когда вы нажмете соответствующую
комбинацию клавиш, система сгенерирует новый уникальный код. Если удалить
квадратные скобки по бокам, то получиться отличный уникальный строковый
идентификатор, готовый к использованию, при этом вызов процедуры AssertMsg
будет выглядеть подобным образом.

AssertMsg(FCount > 0, '{19619100-22B0-11D4-ACD0-009027350D25}');

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

AssertMsg(FCount > 0, $19619100);

4. Категории ошибок

В последнее время,
практически во всех развитых объектно-ориентированных языках, появилась
структурная обработка исключений. Эта возможность поддерживается
операционной системой и позволяет перехватывать нештатные ситуации
возникающие, как в обычном, так и в защищенном режиме системы. Язык Object
Pascal полностью поддерживает все возможности по обработке исключений.
Использование исключений при разработке программ рекомендуется
документацией и поддерживается широким использованием исключений в VCL.
Типичный пример обработки исключений приведен ниже.

try
  FS := TMemoryStream.Create;
  try
    FS.LoadFromFile('sound.dat');
    ...
  finally
    FS.Free;
  end;
except
  FSoundData := nil;
  raise;
end;

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

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

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

Прежде всего, ошибки нужно разделить на две группы — фатальные ошибки и
нефатальные или восстановимые ошибки. Фатальные ошибки — это ошибки
«несовместимые с жизнью», после которых выполнение программы невозможно и
бессмысленно. Фатальная ошибка всегда является неожиданной и
подразумевается маловероятной. Например, любое срабатывание проверки
Assert означает серьезное нарушение логики работы программы. Сбой при
выделении памяти или ресурсов в большинстве случаев также является
невосстановимым. Подавляющее большинство API функций при передаче в них
правильных параметров можно отнести к «надежным» функциям, то есть таким
функциям, в выполнении которых мы уверены, и невыполнение которых
маловероятно, но приводит к фатальным ошибкам. Фатальные ошибки можно
отнести к серьезным недостаткам либо в программе, либо в операционной
системе.

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

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

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

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

Таким образом, мы пришли к пониманию того, что существуют разные группы
ошибок, с разным алгоритмом их обработки. Как уже упоминалось, все ошибки
в библиотеке VCL обрабатываются одинаковым образом. Изменить существующее
положение вещей можно разными способами. Например, в можно анализировать
все типы исключений в обработчике TApplication.OnException. Исключения
таких типов как, например, EAccessViolation, EListError, EAbstractError,
EArrayError, EAssertionFailed и многих других можно рассматривать как
фатальные ошибки, а исключения остальных типов рассматривать как
восстановимые ошибки. При этом откат при восстановимых ошибках выполнять
путем локального перехвата исключения конструкцией try-except-end,
обработки и дальнейшей генерации исключения инструкцией raise. Однако
такой способ не является гибким, так как один и тот же тип исключения в
одной операции может рассматриваться как восстановимый, а в другой — как
фатальный.

Улучшенной разновидностью такого способа является способ, когда все
восстановимые исключения от VCL перехватываются и обрабатываются на
местах, а фатальные исключения транспортируются в глобальный обработчик
TApplication.OnException. Таким образом, глобальный обработчик
рассматривает любое исключение как фатальное. Перехват восстановимых
исключений не занимает много места, так как и было указано раньше,
подавляющее большинство операций можно и нужно рассматривать как
«надежные» операции, то есть приводящие к фатальным ошибкам.

Например, открытие файла можно проводить следующим образом.

try
  // Потенциально опасная операция
  FS := TFileStream('sound.dat', fmOpenRead);
except
  ShowMessage('Невозможно открыть файл данных');
  Exit;
end;
// Проверка размера
if FS.Size <> 1000 then
  Exit;
// "Надежная" операция - все должно выполняться нормально
FS.Position := 0;
FS.ReadBuffer(Fbuffer, 1000);

Вызовы API функций не генерируют исключений, поэтому следует
анализировать и обрабатывать результаты выполнения потенциально опасных
функций, а «надежные» функции обертывать процедурой Win32Check, а еще
лучше специальной процедурой Assert с указанием кода ошибки и уникальной
метки.

procedure AssertWin32(Condition: Boolean; Mark: string);
var
  ExceptAddr: Pointer;
  ExceptMsg: string;
begin
  // Если условие выполняется, то выходим
  if Condition then
    Exit;
  // Получаем адрес вызвавшей нас инструкции Call
  asm
    mov EAX, [EBP+$04]
    mov ExceptAddr, EAX
  end;
  // Получаем сообщение об ошибке
  ExceptMsg := SysErrorMessage(GetLastError);
  // Возбуждаем исключение в месте вызова этой функции
  raise EFatalExcept.Create('Ошибка Win32: ' + ExceptMsg + #13#13+Mark)at
    ExceptAddr;
end;

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

Вы либо полностью контролируете ситуацию, с возможностью отката к
нормальному состоянию программы — «нефатальная ошибка»; либо извиняетесь и
закрываете программу, так как вы не можете корректно обработать эту ошибку
— «фатальная» ошибка. Во втором случае вы должны сделать все возможное,
чтобы информация об ошибке была как можно содержательнее, для того, чтобы
вы могли ее исправить.

5. Тотальный контроль

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

Однако существует еще одна проблема, связанная с тем, что широко
используемая библиотека VCL, а также множество других естественно не
используют выше указанные принципы. Например, при выполнении следующего
кода возникнет исключение от VCL с сообщением «List index out of bounds»,
так как мы запрашиваем на один элемент больше, чем есть в списке. Получив
сообщение о такой ошибке от пользователя, вы вряд ли сможете определить
место программы, где эта ошибка произошла. Поиск такой ошибки затруднен,
даже если она возникла на вашем компьютере, на том, на котором вы
разрабатываете программу. А если такая ошибка возникла у далекого
пользователя, сложность возрастает во много раз, так как вам предстоит еще
и «выбить» всю информацию об ошибке у человека далекого от Delphi в
частности, и от программирования вообще.

for i := 0 to FList.Count do
  FObj := TObject(FList[i]);

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

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

try
  for i := 0 to FList.Count do
    FObj := TObject(FList[i]);
except
  raise AssertInternal('{88A4613E-0ACB-11D4-ACCF-009027350D25}');
end;

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

Получив информацию о возникшей ошибке вы можете:

• с точностью до процедуры узнать место возникновения ошибки;
• узнать тип исключения и параметры ошибки (например ошибочный индекс
  или адрес по которому произошел ошибочный доступ к памяти).

Такая информация значительно облегчает поиск и исправление
ошибок в очень большом проекте.

6. Заключение

Все вышеперечисленное являлось
лишь приблизительным рецептом и пищей для размышления. Точный вариант
комплексной системы обработки ошибок приведен в прилагаемом архиве. Модуль
ATSAssert.pas содержит примеры процедур и функций для обработки фатальных
ошибок. Модуль ATSDialogMain.pas содержит примеры их использования.

7. Пример модуля с функциями комплексной обработки
ошибок

////////////////////////////////////////////////////////////////////////////////
//             ATSTest - иллюстрация комплексной обработки исключений
//                             (c) Николай Мазуркин
// _____________________________________________________________________________
//                      Процедуры обработки фатальных ошибок
////////////////////////////////////////////////////////////////////////////////

unit ATSAssert;

interface

uses Windows, Messages, SysUtils, ActiveX, Forms;

Объявления деклараций используемых функций

Объявляется перечень и
формат функций для комлексного контроля за качеством кода.

////////////////////////////////////////////////////////////////////////////////
// Процедуры обработки фатальных ситуаций
////////////////////////////////////////////////////////////////////////////////
procedure AssertMsg(Condition: Boolean; const Mark: string);
procedure AssertWin32(Condition: Boolean; const Mark: string);
function  AssertInternal(const Mark: string): TObject;
procedure HandleError(const Msg: string);

implementation

////////////////////////////////////////////////////////////////////////////////
// Utils
// _____________________________________________________________________________
// Процедуры обработки фатальных ситуаций
////////////////////////////////////////////////////////////////////////////////

Глобальный обработчик исключений

Глобальный обработчик исключений
устанавливает процедуру обработки на событие Application.OnException. Это
позволяет перехватывать все исключения не пойманные конструкцией
try-except-AssertInternal-end. Хотя таких непойманных исключений быть не
должно, лучше все-таки поставить на них обработчик.

Если вы пишите библиотеку DLL в таком обработчике нет необходимости,
так как все непойманные исключения будут обрабатывать в EXE-модуле.

////////////////////////////////////////////////////////////////////////////////
// TExceptHandler
// _____________________________________________________________________________
// Глобальный обработчик исключений
////////////////////////////////////////////////////////////////////////////////
type
  TExceptHandler = class(TObject)
    procedure OnException(Sender: TObject; E: Exception);
  end;

var
  ExceptHandler: TExceptHandler;

  ////////////////////////////////////////////////////////////////////////////////
  // Обработка исключений
  ////////////////////////////////////////////////////////////////////////////////

procedure TExceptHandler.OnException(Sender: TObject; E: Exception);
begin
  HandleError(PChar(E.Message));
end;

Основная процедура обработки ошибок

Основная процедура обработки
ошибок. Формирует и выводит сообщение, записывает его в посмертный лог и
закрывает программу. Если вы пишете библиотеку DLL, то для каждой
библиотеки можете добавить к сообщению свой дополнительный префикс,
например ‘A’, ‘B’, ‘C’ и т.д. Это поможет быстро определить в каком модуле
произошла ошибка.

////////////////////////////////////////////////////////////////////////////////
// Обработка ошибочной ситуации
////////////////////////////////////////////////////////////////////////////////

procedure HandleError(const Msg: string);
var
  DeadFile: TextFile;
  DeadName: string;
  ErrorMsg: string;
begin
  // Формируем сообщение
  ErrorMsg := Msg + #13#13;
// Если это исключение, то добавим его тип и адрес
  if ExceptObject <> nil then
    ErrorMsg := ErrorMsg + Format('Исключение типа %s, адрес 0x%8.8x'#13#13,
      [ExceptObject.ClassName, DWord(ExceptAddr)]
      );
  ErrorMsg := ErrorMsg + 'Выполнение программы будет прекращено.';
  // Показываем диалог
  MessageBox(0, PChar(ErrorMsg),
    'Фатальная ошибка', MB_OK + MB_ICONWARNING + MB_APPLMODAL + MB_SETFOREGROUND
      + MB_TOPMOST);
  // Генерируем уникальное имя файла
  SetLength(DeadName, MAX_PATH + 10);
  GetTempFileName(PChar(ExtractFilePath(ParamStr(0))), 'err', 0, @DeadName[1]);
  // Записываем ошибку в посмертный лог - на случай если пользователь не догадается
  // записать код ошибки и сообщение.
  AssignFile(DeadFile, DeadName);
  ReWrite(DeadFile);
  WriteLn(DeadFile, ErrorMsg);
  CloseFile(DeadFile);
  // Немедленно закрываем процесс
  ExitProcess(1);
end;

Альтернативная процедура Assert

////////////////////////////////////////////////////////////////////////////////
// Проверка выполнимости условия
////////////////////////////////////////////////////////////////////////////////

procedure AssertMsg(Condition: Boolean; const Mark: string);
begin
  // Если условие выполняется, то выходим сразу
  if Condition then
    Exit;
  // Обрабатываем возникшую ошибку
  HandleError('Фатальная ошибка ' + Mark);
end;

Альтернативная процедура Assert для API-функций

////////////////////////////////////////////////////////////////////////////////
// Проверка выполнимости API-функции
////////////////////////////////////////////////////////////////////////////////

procedure AssertWin32(Condition: Boolean; const Mark: string);
var
  ErrorMsg: string;
begin
  // Если условие выполняется, то выходим
  if Condition then
    Exit;
  // Получаем сообщение об ошибке
  ErrorMsg := SysErrorMessage(GetLastError);
  // Обрабатываем возникшую ошибку
  HandleError('Фатальная ошибка ' + Mark + #13#13+ErrorMsg);
end;

Функция для тотального контроля
исключений

Функция для перехвата исключений от VCL и неудачных
обращений к памяти. Добаляет к тексту исключения уникальную метку и
генерирует ошибку.

////////////////////////////////////////////////////////////////////////////////
// Генерация фатального исключения
////////////////////////////////////////////////////////////////////////////////

function AssertInternal(const Mark: string): TObject;
begin
  // Проверяем тип сгенерированного исключения и обрабатываем возникшую ошибку
  if ExceptObject is Exception then
    HandleError('Фатальная ошибка ' + Mark + #13#13+
     PChar(Exception(ExceptObject).Message))
  else
    HandleError('Фатальная ошибка ' + Mark);
  // Следующая строчка никогда не выполнится, она нужна для успокоения компилятора
  Result := nil;
end;

Инициализация модуля

Создание и настройка глобального обработчика
исключения на событии TApplication.OnException.

////////////////////////////////////////////////////////////////////////////////
// Автоматическое создание глобального обработчика исключения
////////////////////////////////////////////////////////////////////////////////
initialization
  ExceptHandler := TExceptHandler.Create;
  Application.OnException := ExceptHandler.OnException;

end.

8. Пример использования системы комплексного
контроля

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

Исходные
тексты функций комплексного контроля и пример поясняющий их работу (8
кБ)

Go Up to Classes and Objects Index

This topic covers the following material:

• A conceptual overview of exceptions and exception handling
• Declaring exception types
• Raising and handling exceptions

About Exceptions

An exception is raised when an error or other event interrupts normal execution of a program. The exception transfers control to an exception handler, which allows you to separate normal program logic from error-handling. Because exceptions are objects, they can be grouped into hierarchies using inheritance, and new exceptions can be introduced without affecting existing code. An exception can carry information, such as an error message, from the point where it is raised to the point where it is handled.

When an application uses the SysUtils unit, most runtime errors are automatically converted into exceptions. Many errors that would otherwise terminate an application — such as insufficient memory, division by zero, and general protection faults — can be caught and handled.

When To Use Exceptions

Exceptions provide an elegant way to trap runtime errors without halting the program and without awkward conditional statements. The requirements imposed by exception handling semantics impose a code/data size and runtime performance penalty. While it is possible to raise exceptions for almost any reason, and to protect almost any block of code by wrapping it in a try…except or try…finally statement, in practice these tools are best reserved for special situations.

Exception handling is appropriate for errors whose chances of occurring are low or difficult to assess, but whose consequences are likely to be catastrophic (such as crashing the application); for error conditions that are complicated or difficult to test for in if…then statements; and when you need to respond to exceptions raised by the operating system or by routines whose source code you don’t control. Exceptions are commonly used for hardware, memory, I/O, and operating-system errors.

Conditional statements are often the best way to test for errors. For example, suppose you want to make sure that a file exists before trying to open it. You could do it this way:

try
    AssignFile(F, FileName);
    Reset(F);     // raises an EInOutError exception if file is not found
except
    on Exception do ...
end;

But you could also avoid the overhead of exception handling by using:

if FileExists(FileName) then    // returns False if file is not found; raises no exception

begin
    AssignFile(F, FileName);
    Reset(F);
end;

Assertions provide another way of testing a Boolean condition anywhere in your source code. When an Assert statement fails, the program either halts with a runtime error or (if it uses the SysUtils unit) raises an SysUtils.EAssertionFailed exception. Assertions should be used only to test for conditions that you do not expect to occur.

Declaring Exception Types

Exception types are declared just like other classes. In fact, it is possible to use an instance of any class as an exception, but it is recommended that exceptions be derived from the SysUtils.Exception class defined in SysUtils.

You can group exceptions into families using inheritance. For example, the following declarations in SysUtils define a family of exception types for math errors:

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

Given these declarations, you can define a single SysUtils.EMathError exception handler that also handles SysUtils.EInvalidOp, SysUtils.EZeroDivide, SysUtils.Overflow, and SysUtils.EUnderflow.

Exception classes sometimes define fields, methods, or properties that convey additional information about the error. For example:

type EInOutError = class(Exception)
       ErrorCode: Integer;
     end;

Raising and Handling Exceptions

To raise an exception object, use an instance of the exception class with a raise statement. For example:

raise EMathError.Create;

In general, the form of a raise statement is

raise object at address

where object and at address are both optional. When an address is specified, it can be any expression that evaluates to a pointer type, but is usually a pointer to a procedure or function. For example:

raise Exception.Create('Missing parameter') at @MyFunction;

Use this option to raise the exception from an earlier point in the stack than the one where the error actually occurred.

When an exception is raised — that is, referenced in a raise statement — it is governed by special exception-handling logic. A raise statement never returns control in the normal way. Instead, it transfers control to the innermost exception handler that can handle exceptions of the given class. (The innermost handler is the one whose try…except block was most recently entered but has not yet exited.)

For example, the function below converts a string to an integer, raising an SysUtils.ERangeError exception if the resulting value is outside a specified range.

function StrToIntRange(const S: string; Min, Max: Longint): Longint;
begin
    Result := StrToInt(S);   // StrToInt is declared in SysUtils
    if (Result < Min) or (Result > Max) then
       raise ERangeError.CreateFmt('%d is not within the valid range of %d..%d', [Result, Min, Max]);
end;

Notice the CreateFmt method called in the raise statement. SysUtils.Exception and its descendants have special constructors that provide alternative ways to create exception messages and context IDs.

A raised exception is destroyed automatically after it is handled. Never attempt to destroy a raised exception manually.

Note: Raising an exception in the initialization section of a unit may not produce the intended result. Normal exception support comes from the SysUtils unit, which must be initialized before such support is available. If an exception occurs during initialization, all initialized units — including SysUtils — are finalized and the exception is re-raised. Then the exception is caught and handled, usually by interrupting the program. Similarly, raising an exception in the finalization section of a unit may not lead to the intended result if SysUtils has already been finalized when the exception has been raised.

Try…except Statements

Exceptions are handled within try…except statements. For example:

try
   X := Y/Z;
   except
     on EZeroDivide do HandleZeroDivide;
end;

This statement attempts to divide Y by Z, but calls a routine named HandleZeroDivide if an SysUtils.EZeroDivide exception is raised.

The syntax of a try…except statement is:

try statements except exceptionBlock end

where statements is a sequence of statements (delimited by semicolons) and exceptionBlock is either:

• another sequence of statements or
• a sequence of exception handlers, optionally followed by

else statements

An exception handler has the form:

on identifier: type do statement

where identifier: is optional (if included, identifier can be any valid identifier), type is a type used to represent exceptions, and statement is any statement.

A try…except statement executes the statements in the initial statements list. If no exceptions are raised, the exception block (exceptionBlock) is ignored and control passes to the next part of the program.

If an exception is raised during execution of the initial statements list, either by a raise statement in the statements list or by a procedure or function called from the statements list, an attempt is made to ‘handle’ the exception:

• If any of the handlers in the exception block matches the exception, control passes to the first such handler. An exception handler ‘matches’ an exception just in case the type in the handler is the class of the exception or an ancestor of that class.
• If no such handler is found, control passes to the statement in the else clause, if there is one.
• If the exception block is just a sequence of statements without any exception handlers, control passes to the first statement in the list.

If none of the conditions above is satisfied, the search continues in the exception block of the next-most-recently entered try…except statement that has not yet exited. If no appropriate handler, else clause, or statement list is found there, the search propagates to the next-most-recently entered try…except statement, and so forth. If the outermost try…except statement is reached and the exception is still not handled, the program terminates.

When an exception is handled, the stack is traced back to the procedure or function containing the try…except statement where the handling occurs, and control is transferred to the executed exception handler, else clause, or statement list. This process discards all procedure and function calls that occurred after entering the try…except statement where the exception is handled. The exception object is then automatically destroyed through a call to its Destroy destructor and control is passed to the statement following the try…except statement. (If a call to the Exit, Break, or Continue standard procedure causes control to leave the exception handler, the exception object is still automatically destroyed.)

In the example below, the first exception handler handles division-by-zero exceptions, the second one handles overflow exceptions, and the final one handles all other math exceptions. SysUtils.EMathError appears last in the exception block because it is the ancestor of the other two exception classes; if it appeared first, the other two handlers would never be invoked:

try
  ...
except
  on EZeroDivide do HandleZeroDivide;
  on EOverflow do HandleOverflow;
  on EMathError do HandleMathError;
end;

An exception handler can specify an identifier before the name of the exception class. This declares the identifier to represent the exception object during execution of the statement that follows on…do. The scope of the identifier is limited to that statement. For example:

try
  ...
except
  on E: Exception do ErrorDialog(E.Message, E.HelpContext);
end;

If the exception block specifies an else clause, the else clause handles any exceptions that aren’t handled by the block’s exception handlers. For example:

try
  ...
except
  on EZeroDivide do HandleZeroDivide;
  on EOverflow do HandleOverflow;
  on EMathError do HandleMathError;
else
  HandleAllOthers;
end;

Here, the else clause handles any exception that isn’t an SysUtils.EMathError.

An exception block that contains no exception handlers, but instead consists only of a list of statements, handles all exceptions. For example:

try
   ...
except
   HandleException;
end;

Here, the HandleException routine handles any exception that occurs as a result of executing the statements between try and except.

Re-raising Exceptions

When the reserved word raise occurs in an exception block without an object reference following it, it raises whatever exception is handled by the block. This allows an exception handler to respond to an error in a limited way and then re-raise the exception. Re-raising is useful when a procedure or function has to clean up after an exception occurs but cannot fully handle the exception.

For example, the GetFileList function allocates a TStringList object and fills it with file names matching a specified search path:

function GetFileList(const Path: string): TStringList;
var
  I: Integer;
  SearchRec: TSearchRec;
begin
  Result := TStringList.Create;
  try
    I := FindFirst(Path, 0, SearchRec);
    while I = 0 do
      begin
          Result.Add(SearchRec.Name);
          I := FindNext(SearchRec);
      end;
  except
      Result.Free;
      raise;
  end;
end;

GetFileList creates a TStringList object, then uses the FindFirst and FindNext functions (defined in SysUtils) to initialize it. If the initialization fails — for example because the search path is invalid, or because there is not enough memory to fill in the string list — GetFileList needs to dispose of the new string list, since the caller does not yet know of its existence. For this reason, initialization of the string list is performed in a try…except statement. If an exception occurs, the statement’s exception block disposes of the string list, then re-raises the exception.

Nested Exceptions

Code executed in an exception handler can itself raise and handle exceptions. As long as these exceptions are also handled within the exception handler, they do not affect the original exception. However, once an exception raised in an exception handler propagates beyond that handler, the original exception is lost. This is illustrated by the Tan function below:

type
   ETrigError = class(EMathError);
   function Tan(X: Extended): Extended;
   begin
      try
        Result := Sin(X) / Cos(X);
      except
        on EMathError do
        raise ETrigError.Create('Invalid argument to Tan');
      end;
   end;

If an SysUtils.EMathError exception occurs during execution of Tan, the exception handler raises an ETrigError. Since Tan does not provide a handler for ETrigError, the exception propagates beyond the original exception handler, causing the SysUtils.EMathError exception to be destroyed. To the caller, it appears as if the Tan function has raised an ETrigError exception.

Try…finally Statements

Sometimes you want to ensure that specific parts of an operation are completed, whether or not the operation is interrupted by an exception. For example, when a routine acquires control of a resource, it is often important that the resource be released, regardless of whether the routine terminates normally. In these situations, you can use a try…finally statement.

The following example shows how code that opens and processes a file can ensure that the file is ultimately closed, even if an error occurs during execution:

Reset(F);
try
   ... // process file F
finally
   CloseFile(F);
end;

The syntax of a try…finally statement is

try statementList1 finally statementList2 end

where each statementList is a sequence of statements delimited by semicolons. The try…finally statement executes the statements in statementList1 (the try clause). If statementList1 finishes without raising exceptions, statementList2 (the finally clause) is executed. If an exception is raised during execution of statementList1, control is transferred to statementList2; once statementList2 finishes executing, the exception is re-raised. If a call to the Exit, Break, or Continue procedure causes control to leave statementList1, statementList2 is automatically executed. Thus the finally clause is always executed, regardless of how the try clause terminates.

If an exception is raised but not handled in the finally clause, that exception is propagated out of the try…finally statement, and any exception already raised in the try clause is lost. The finally clause should therefore handle all locally raised exceptions, so as not to disturb propagation of other exceptions.

Standard Exception Classes and Routines

The SysUtils and System units declare several standard routines for handling exceptions, including ExceptObject, ExceptAddr, and ShowException. SysUtils, System and other units also include dozens of exception classes, all of which (aside from OutlineError) derive from SysUtils.Exception.

The SysUtils.Exception class has properties called Message and HelpContext that can be used to pass an error description and a context ID for context-sensitive online documentation. It also defines various constructor methods that allow you to specify the description and context ID in different ways.

See Also

• Classes and Objects (Delphi)
• Fields (Delphi)
• Methods (Delphi)
• Properties (Delphi)
• Nested Type Declarations
• Class References
• Operator Overloading (Delphi)
• Class and Record Helpers (Delphi)
• Handling Exceptions