Лучшая практика для выполнения вложенного оператора TRY / FINALLY

как насчет следующего:

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
    cds3  : TClientDataSet;
    cds4  : TClientDataSet;
begin
  cds1      := Nil;
  cds2      := Nil;
  cds3      := Nil;
  cds4      := Nil;
  try
    cds1      := TClientDataSet.Create(nil);
    cds2      := TClientDataSet.Create(nil);
    cds3      := TClientDataSet.Create(nil);
    cds4      := TClientDataSet.Create(nil);
    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////
  finally
    freeandnil(cds4);
    freeandnil(cds3);
    freeandnil(cds2);
    freeandnil(Cds1);
  end;
end;

Это делает его компактным и пытается освободить только те экземпляры, которые были созданы. На самом деле нет необходимости выполнять вложение, поскольку ЛЮБОЙ сбой приведет к переходу к окончанию и выполнению всей очистки в приведенном вами примере.

Лично я стараюсь не вкладываться в один и тот же метод ... за исключением сценария try / try / except / finally. Если мне нужно выполнить вложенность, то для меня самое время подумать о рефакторинге в вызов другого метода.

РЕДАКТИРОВАТЬ немного поправили благодаря комментариям mghie и utku.

РЕДАКТИРОВАТЬ изменил создание объекта так, чтобы он не ссылался на приложение, поскольку в этом примере это не обязательно.

Я бы использовал что-то вроде этого:

var
  Safe: IObjectSafe;
  cds1 : TClientDataSet;
  cds2 : TClientDataSet;
  cds3 : TClientDataSet;
  cds4 : TClientDataSet;
begin
  Safe := ObjectSafe;
  cds1 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  cds2 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  cds3 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  cds4 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  ///////////////////////////////////////////////////////////////////////
  ///      DO WHAT NEEDS TO BE DONE
  ///////////////////////////////////////////////////////////////////////

  // if Safe goes out of scope it will be freed and in turn free all guarded objects
end;

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

РЕДАКТИРОВАТЬ:

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

ИЗМЕНИТЬ 2:

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

Есть еще один вариант кода без вложенной попытки ... наконец, это только что пришло мне в голову. Если вы не создаете компоненты с параметром AOwner конструктора, установленным в nil, вы можете просто использовать управление временем жизни, которое VCL предоставляет вам бесплатно:

var
  cds1: TClientDataSet;
  cds2: TClientDataSet;
  cds3: TClientDataSet;
  cds4: TClientDataSet;
begin
  cds1 := TClientDataSet.Create(nil);
  try
    // let cds1 own the other components so they need not be freed manually
    cds2 := TClientDataSet.Create(cds1);
    cds3 := TClientDataSet.Create(cds1);
    cds4 := TClientDataSet.Create(cds1);

    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////

  finally
    cds1.Free;
  end;
end;

Я большой сторонник маленького кода (если он не слишком запутан).

Если вы хотите пойти по этому (IMO) уродливому маршруту (групповая обработка с инициализацией до нуля, чтобы знать, требуется ли освобождение), вы, по крайней мере, ДОЛЖНЫ гарантировать, что вы не позволите исключению в одном из деструкторов предотвратить освобождение остальной части ваши объекты.
Что-то вроде:

function SafeFreeAndNil(AnObject: TObject): Boolean;
begin
  try
    FreeAndNil(AnObject);
    Result :=  True;
  except
    Result := False;
  end;
end;

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
    IsOK1 : Boolean;
    IsOK2 : Boolean;
begin
  cds1      := Nil;
  cds2      := Nil; 
 try
    cds1      := TClientDataSet.Create(nil);
    cds2      := TClientDataSet.Create(nil);    
    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////
  finally
    IsOk2 := SafeFreeAndNil(cds2);    // an error in freeing cds2 won't stop execution
    IsOK1 := SafeFreeAndNil(Cds1);
    if not(IsOk1 and IsOk2) then
      raise EWhatever....
  end;
end;

Есть хорошее видео об исключениях в конструкторах и деструкторах

Он показывает несколько хороших примеров, таких как:

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
begin
  cds1      := Nil;
  cds2      := Nil; 
 try
    cds1      := TClientDataSet.Create(nil);
    cds2      := TClientDataSet.Create(nil);    
    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////
  finally
    freeandnil(cds2);    //// what has if there in an error in the destructor of cds2
    freeandnil(Cds1);
  end;
end;

Что там если в деструкторе cds2 ошибка

Cds1 не будет уничтожен

РЕДАКТИРОВАТЬ

Еще один хороший ресурс:

Джим МакКит отличное видео о отложенной обработке исключений в диапазоне кода III, где он говорит о проблемах с обработкой исключений. в блоке finally.

@mghie: Delphi имеет выделенные в стеке объекты:

type
  TMyObject = object
  private
    FSomeField: PInteger;
  public
    constructor Init;
    destructor Done; override;
  end;

constructor TMyObject.Init;
begin
  inherited Init;
  New(FSomeField);
end;

destructor TMyObject.Done;
begin
  Dispose(FSomeField);
  inherited Done;
end;

var
  MyObject: TMyObject;

begin
  MyObject.Init;
  /// ...
end;

К сожалению, как показано в приведенном выше примере: объекты, выделенные стеком, не предотвращают утечки памяти.

Таким образом, для этого все равно потребуется вызов деструктора следующим образом:

var
  MyObject: TMyObject;

begin
  MyObject.Init;
  try
    /// ...
  finally
    MyObject.Done;
  end;
end;

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