So eine ich beuge mal vor allem irgendwie vor Funktion ist absoluter Overkill und führt nur zu einem unsauberen Programmierstil. Wird ja immer alles so schön aufgeräumt
am Schluss.
Gut im normalen Betrieb dauert es ca. 1h bis der Speicher überläuft, aber wir haben keinen MemLeak - dann ist doch alles gut, oder etwa nicht?
Ein super Anti-Beispiel ist die FireMonkey ListBox aus XE7. Füll da mal so 10.000 Elemente rein (ist nur damit man auch was sieht) und dann gemütlich durch die Liste scrollen - rauf und runter. Toll, geht, aber was sagt der TaskManager zum Thema Speicherbedarf: Der wächst und wächst und wächst ... mit jedem Scrollen und hört einfach nicht auf. Es gibt aber keinen MemLeak, denn alles wird am Ende ja brav aufgeräumt. Dort jetzt den Fehler zu finden ist aufwändig. Bei einem MemLeak schaue ich mir die Instanzen an, wo es die meisten Leaks gibt und verfolge, wer die erzeugt und schwupps bin ich an der fehlerhaften Stelle.
So habe ich die MemLeaks in dem RestResponseDatasetAdapter gefunden und ausgemerzt.
Diese Art und Weise der Programmierung ist ähnlich schlimm, wie das paranoide
Exception fangen. Lasst euch doch die Exceptions (so früh wie möglich) und die Leaks um die Ohren fliegen, dann wisst ihr wenigstens, wo es noch etwas zu tun gibt (sozusagen als automatischer ToDo-Eintrag).
Falls es nicht bekannt sein sollte: Wenn sich die Anwendung beendet wird auch der gesamte Speicher der Anwendung freigegeben, ob Leak oder nicht, es bleibt nichts zurück.