Die
Exception EOutOfResources ist eine besondere
Exception, da sie von der EOutOfMemory -
Exception abgeleitet wird. Erstell mal ein Test-Projekt, binde FastMM ein und auf die Form1 klatscht du ein Button drauf. Im Click-Handler schreibst du folgendes:
Delphi-Quellcode:
procedure TForm1.Button1Click(Sender: TObject);
begin
raise EOutOfResources.Create('bla bla blub');
end;
Dann starte das Testprogramm, klick den Button und beende das Programm: und siehe da: EOutOfResources wird nicht freigegeben. Wenn du jetzt irgend eine andere beliebige
Exception (außer EOutOfMemory) benutzt, wird diese korrekt freigegeben.
Exceptions, die von EOutOfMemory abgeleitet sind, dürfen also nicht so geworfen werden. Für die EOutOfMemory gibt es in der SysUtils-
Unit die Funktion
OutOfMemoryError
, ob es das für EOutOfResources auch gibt, weiß ich nicht.
Die Ausnahme ist sehr sinnvoll: wenn kein Speicherplatz mehr vorhanden ist, soll ja diese
Exception geworfen werden. Blöd wäre jetzt nur, wenn für die
Exception auch kein Speicher mehr vorhanden wäre. Daher wird eine Instanz der
Exception global beim Start angelegt und diese Instanz wird einfach immer wieder neu geworfen.
[Ergänzung]
Mal ein Auszug aus der Delphi-Hilfe für EHeapException:
Zitat:
Die von EHeapException abgeleiteten Klassen EOutOfMemory und EInvalidPointer werden dazu verwendet, fehlgeschlagene Zuweisungen von dynamischem Speicher und ungültige Zeigeroperationen abzufangen.
Hinweis: Speicher für diese Exceptions wird im Voraus zugewiesen, sobald eine Anwendung startet. Die Zuweisung bleibt bestehen, solange die Anwendung läuft. EHeapException oder Nachkommen davon dürfen niemals direkt ausgelöst werden.