Архив для месяца: Февраль, 2013

    Интересно, на сколько читатель уверен в своих знаниях подводных камней в работе с исключениями в Delphi.  Я решил подготовить три наиболее часто встречаемых ошибки в  рабочем проекте. Надо признаться, некоторые моменты меня удивили. В том числе и ответ на вопрос «в какой момент удаляются объекты исключений».
    Каждый может проверить свои познания подводных камней.  В листинге ниже приведены три метода Error#, каждый из которых ведет к определенной проблеме.
Пояснения я приведу вслед за кодом.

procedure  RaiseOSException;
var
   res: integer;
   zero: integer;
begin
   zero := 0;
   res := 5 div zero;
end;

function FormatException(E:Exception): Exception;
begin
if not (E is EMyException) then
result := EMyException.Create(E.Message)
else
begin
     E.message :=  Format('Ошибка обработки исключения: %s', [E.Message]);
result := E;
  endl
end;


procedure Error1;
begin
try
    RaiseOSException;
except
on E: Exception do
begin
      E.Message := Format('Заворачиваем в свой текст: %s', [E.Message]);
Raise;
end;
end;
end;

procedure Error2;
begin
try
raise EMyException.Create('Alarm!!111');
except
on E: Exception do
begin      
Raise FormatException(E);
end;
end;
end;

procedure Error3;
begin
try
raise Exception.Create('Alarm!!111');;
except
Raise FormatException(AcquireExceptionObject);
end;
end;
Ответы:


Error1 — потеря изменений в сообщение исключения;
Error2 — Ошибка Access Violation
Error3 — Утечка памяти

Разберем каждый случай более детально:



Потеря сообщений


    В методе Error1 мы изменяем текст исходного сообщения и возбуждаем исключение вновь. Но в диалоге исключения мы не увидим текста с «Заворачиваем в свой текст: %s».
    При возбуждение внешнего исключения Delphi заворачивает его в обертку — собственное исключения и дает обработать в блоке except..end.  Далее, в вызове Raise вызывается System._RaiseAgain в котором происходит удаление объекта делфового исключения(в котором мы и сделали изменение данных поля Message), а дальше возбуждается исходное внешнее исключение  которое ничего не знает про наш новый текст сообщения. 
    Более подробно можно найти описание на stackoverflow.


Ошибка Access Violation (Или «в какой момент удаляются объекты исключений»)


   В методе Error2 мы поймали исключение, хотим отформатировать его текст и пробросить дальше. Однако это приведет к проблеме.  
   Проблема  случая из метода Error2 заключается в том, что Delphi попытается дважды удалить один и тот же объект исключения. Первый раз Raise FormatException(E),  второй раз скорее всего где нибудь в TApplication, в завершения цикла обработки исключений. Ответ находится в System._HandleAnyException в которой каждый сможет найти комментарий:
 { we come here if an exception handler has thrown yet another exception }
        { we need to destroy the exception object and pop the raise list. }
   Синтаксис «Raise Argument: Exception;» подразумевает что мы пытаемся возбудить другой объект исключения, а не тот, что находится сейчас на вершине стека возбужденных исключений. Для этого вычищаем объект исключения, что находится на вершине стека и вталкиваем в стек его новый объект. Проблема заключается в том, что удаляемый и вталкиваемый объект являются одним и тем же объектом. 
  Единственное место, где в документации Embarcadero явно говориться, что так делать нельзя нашел в статье Handling exceptions in Delphi. 
   Правильно выполнить вызов raise без аргументов(«Raise;»), либо использовать метод AcquireExceptionObject. О нем ниже.

Утечка памяти

    В Error3 мы вместо пойманного исключения стандартного класса создаем собственное исключение, которое может более точно сообщить о проблеме при обработке в вызывающем коде. Нюанс заключается в том, что исходный  объект исключения получаем через AcquireExceptionObject. Данный метод может оказаться незаменим, например если мы хотим передать исключение из одного потока в другой. AcquireExceptionObject возлагает на нас ответственность за дальнейшее освобождения памяти полученного объекта исключения, а Delphi тем временем «умывает руки».
Справка Delphi сообщает, что за методом  AcquireExceptionObject должен следовать ReleaseExceptionObject который уменьшает счетчик ссылок на фрейм исключения(структура в rtl описывающая исключение). Получается, что  в Error3 мы забыли вызвать метод ReleaseExceptionObject? Нет. Вызов ReleaseExceptionObject нам ничем не поможет: объект  утечет в любом случае.
   В действительности счет ссылок и ReleaseExceptionObject  актуальны только для Linux. В модуле System есть объявление типа TRaiseFrame — фрейма исключений, в случае компиляции под Windows счетчик ссылок не предусмотрен. Вот текст метода:
function AcquireExceptionObject: Pointer;
begin
if RaiseListPtr <> nil then
begin
Result := PRaiseFrame(RaiseListPtr)^.ExceptObject;
    PRaiseFrame(RaiseListPtr)^.ExceptObject := nil;
end
else
Result := nil;
end;
Метод AcquireExceptionObject «забывает» ссылку на объект исключения во фрейме исключения. А при стандартном попытке удаление исключения  ничего не произойдет, так как предусмотрена проверка на nil в деструкторе объекта:
procedure TObject.Free;
begin
if Self <> nil then
    Destroy;
end;
Именно по этому вызов из проблемы которая описана выше не приведет к AV:
except
  E := AcquireExceptionObject;
Raise E; // В данном случае это правильный код
end;
А для метода test3 наиболее правильным будет решение отказаться от AcquireExceptionObject, и получать объект используя синтаксис On E: Exception do. Но все же, если удобнее использовать AcquireExceptionObject, то за ним должен следовать Raise Argument;  либо явный вызов деструктора:
procedure Error3;
var
  e : Exception;
begin
try
raise Exception.Create('Alarm!!111');;
except
     e := AcquireExceptionObject;
try
Raise FormatException(e);
finally
       FreeAndNil(e);
end;
end;
end;
Более подробно, про то, что справка иногда обманывает qc.embarcadero.com
Подводя итог, как делать нельзя:
//AV
On E: Exception do
raise E;

//Утечка
E := AcquireExceptionObject;
raise EMyException.Create(E.Message);

//Утечка
E := AcquireExceptionObject;
try
   Foo(E);
finally
     ReleaseExceptionObject(E); //Вызов метода бессмысленнен
end;