delphi – 为什么我不应该使用“如果Assigned()”之前使用或释放​​的东西？

这个问题是人们对stackoverflow的一个特定评论的延续，我已经看到了几个不同的时间现在。我，以及开发人员教我德尔福，为了保持安全，总是放一个检查如果assign()释放对象之前，在做其他各种事情之前。但是，我现在被告知，我不应该添加这个检查。我想知道如果应用程序编译/运行如果我这样做，或者如果它不会影响任何结果的任何差异…

if assigned(SomeObject) then SomeObject.Free;

让我们说，我有一个窗体，我在窗体的创建时在后台创建一个位图对象，当我完成它时释放它。现在我想我的问题是我习惯了把这个检查很多我的代码，当我试图访问的对象，可能在某个时候可能已经释放。我已经使用它，即使没有必要。我喜欢彻底…

unit Unit1;

interface

uses
  Windows,Messages,SysUtils,Variants,Classes,Graphics,Controls,Forms,Dialogs;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    FBitmap: TBitmap;
  public
    function LoadBitmap(const Filename: String): Bool;
    property Bitmap: TBitmap read FBitmap;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  FBitmap:= TBitmap.Create;
  LoadBitmap('C:\Some Sample Bitmap.bmp');
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  if assigned(FBitmap) then begin //<-----
    //Do some routine to close file
    FBitmap.Free;
  end;
end;

function TForm1.LoadBitmap(const Filename: String): Bool;
var
  EM: String;
  function CheckFile: Bool;
  begin
    Result:= False;
    //Check validity of file,return True if valid bitmap,etc.
  end;
begin
  Result:= False;
  EM:= '';
  if assigned(FBitmap) then begin //<-----
    if FileExists(Filename) then begin
      if CheckFile then begin
        try
          FBitmap.LoadFromFile(Filename);
        except
          on e: exception do begin
            EM:= EM + 'Failure loading bitmap: ' + e.Message + #10;
          end;
        end;
      end else begin
        EM:= EM + 'Specified file is not a valid bitmap.' + #10;
      end;
    end else begin
      EM:= EM + 'Specified filename does not exist.' + #10;
    end;
  end else begin
    EM:= EM + 'Bitmap object is not assigned.' + #10;
  end;
  if EM <> '' then begin
    raise Exception.Create('Failed to load bitmap: ' + #10 + EM);
  end;
end;

end.

现在让我们说，我引入一个新的自定义列表对象TMyListItem TMyList。对于这个列表中的每个项目，当然我必须创建/释放每个项目对象。有几种不同的方式创建一个项目，以及一些不同的方式来销毁一个项目(添加/删除是最常见的)。我相信这是一个很好的做法，把这种保护在这里…

procedure TMyList.Delete(const Index: Integer);
var
  I: TMyListItem;
begin
  if (Index >= 0) and (Index < FItems.Count) then begin
    I:= TMyListItem(FItems.Objects[Index]);
    if assigned(I) then begin //<-----
      if I <> nil then begin
        I.DoSomethingBeforeFreeing('Some Param');
        I.Free;
      end;
    end;
    FItems.Delete(Index);
  end else begin
    raise Exception.Create('My object index out of bounds ('+IntToStr(Index)+')');
  end;
end;

在许多情况下，至少我希望对象仍然创建之前，我尝试释放它。但是你永远不知道在未来某个对象在它应该发生之前被释放的情况下会发生什么。我一直用这个检查，但现在我被告知我不应该，我还是不明白为什么。

编辑

这里有一个例子，试图向你解释为什么我有这样做的习惯：

procedure TForm1.FormDestroy(Sender: TObject);
begin
  SomeCreatedobject.Free;
  if SomeCreatedobject = nil then
    ShowMessage('Object is nil')
  else
    ShowMessage('Object is not nil');
end;

我的观点是如果SomeCreatedobject<> nil与Assigned(SomeCreatedobject)不同，因为释放SomeCreatedobject后，它不会计算为nil。所以两个检查都应该是必要的。

if obj<>nil

if Assigned(obj)

procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

if obj1 <> nil then
  obj1.Free;
if obj2 <> nil then
  obj2.Free;
if obj3 <> nil then
  obj3.Free;
....

obj1.Free;
obj2.Free;
obj3.Free;
....

FSettings.Save;
FSettings.Free;

if Assigned(FSettings) then
begin
  FSettings.Save;
  FSettings.Free;
end;

constructor TMyObject.Create;
begin
  inherited;
  FSettings := TSettings.Create;
end;

destructor TMyObject.Destroy;
begin
  FSettings.Free;
  inherited;
end;

procedure TMyObject.Update;
begin
  if Assigned(FSettings) then
    FSettings.Update;
end;

constructor TMyObject.Create(UseLogging: Boolean);
begin
  inherited Create;
  if UseLogging then
    FLogger := TLogger.Create;
end;

destructor TMyObject.Destroy;
begin
  FLogger.Free;
  inherited;
end;

procedure TMyObject.FlushLog;
begin
  if Assigned(FLogger) then
    FLogger.Flush;
end;