Ich bin nur ein wenig enttäuscht von MadExcept, so dass es mir wirklich gar kein Hinweis geben konnte. Ist technisch aber sicher auch nicht ganz einfach.
Je mehr man auf Klassen setzt, umso leichter wird die Fehlersuche.
Man kann z.B. dynamischee Arrays direkt in der Anwendung, der "Businesslogik", benützen.
Oder man kapselt das Array innerhalb einer Klasse und lässt nur einen kontrollierten Zugriff über die Methoden der Klasse zu.
Insbeondere sollte man Resourcen (Speicher ist auch eine Resource) immer unter die Kontrolle einer Klasse stellen.
Das heisst dann konkret, dass AllocMem und FreeMem nur im geschützten Kontext einer Klasse aufgerufen werden.
Dann testet man diese Klasse in einer isolierten Umgebung (aka Testprogramm) und kann so sicherstellen, dass die Klasse in sich keine Speicher- oder Resourcenlecks hat.
Findet man später in der Anwendung ein Speicherleck ist die Wahrscheinlichkeit höher, dass man den Klassennamen angezeigt bekommt und so gezielt suchen kann.
Manchmal bekommt man nur allgemeine Klassennamen gemeldet (z.B. TStringList x 14), dann kann man auch von TStringList abgeleitete Klassen einsetzen.
Kleines Beispiel dazu:
Delphi-Quellcode:
// Klasse zum Laden von Daten aus einer Datei
// wird zum Datenimport verwendet
// die Datei darf nicht leer sein
TImportStringList = class(TStringList)
public
procedure LoadFromFile(const FileName: string); override;
end;
procedure TImportStringList.LoadFromFile(const FileName: string);
begin
inherited;
if count = 0 then
raise EBadImportFile.CreateFmt('Datei %s ist leer', [FileName]);
end;
So schlägt man zwei Fliegen mit einer Klappe.
Man kann kleine Teile der Funktionalität an TImportStringList übertragen (prüfen ob Datei leer ist) und ausserdem bekommt man bei einem Speicherleck gezielte Info wo zu suchen ist.
Die ganzen Punkte oben gelten speziell für sehr grosse Anwendungen mit Hunderten von Units.
Bei kleinen Anwendungen braucht man nicht so viel Aufwand zu treiben.