Auf die Idee, es so leicht zu prüfen war ich jetzt garnicht gekommen
Hatte nur keine große Lust es zu debuggen und hatte die Hoffnung es weiß schon einer
Hab es gleich nochmal rekursiv probiert.
Delphi-Quellcode:
destructor EMyException.Destroy;
begin
ShowMessage('
Destroy: ' +
Message);
inherited;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
try
try
raise EMyException.Create('
Test 1');
except
on E:
Exception do begin
ShowMessage('
OnExcept: ' + E.
Message);
raise EMyException.Create('
Test 2');
end;
end;
except
on E:
Exception do
ShowMessage('
OnExcept: ' + E.
Message);
{X}
end;
ShowMessage('
End');
end;
Es wird also immer gleich nach seiner letzen Verwendung freigegeben.
Und hier demnach erst nach dem 2. Try-Except-Block.
Delphi-Quellcode:
procedure TForm1.Button1Click(Sender: TObject);
begin
try
try
raise EMyException.Create('
Test 1');
except
on E:
Exception do begin
ShowMessage('
OnExcept: ' + E.
Message);
raise;
end;
end;
except
on E:
Exception do
ShowMessage('
OnExcept: ' + E.
Message);
end;
ShowMessage('
End');
end;
Nja, es hätte ja sein können, daß bis alle Objekte mindestens bis zur letzen Except-Ebene aufgehoben werden
und man somit eine Art Backtacking hätte durchführen können, um so alle nachfolgenden(vorhergehenden)
Exception rauszubekommen.
Also daß man z.B. an Punkt {X} auch noch von der
Exception 'Test 1' hätte etwas erfahren können.
Jedenfalls hätte ich hier durch das RaiseListPtr soetwas vermutet.
Delphi-Quellcode:
{Unit System}
function ExceptObject: TObject;
begin
if RaiseListPtr <>
nil then
Result := PRaiseFrame(RaiseListPtr)^.ExceptObject
else
Result :=
nil;
end;