Ogólnie zgadzam się z @grzegorz_so – jeśli kod może się wykrzaczyć, to sekcja try finally
zapobiega wyciekom pamięci. Poza tym do kompletu używa się bloków try except
, aby nie utracić kontroli nad przepływem sterowania w razie pojawienia się wyjątku. Jest to szczególnie ważne w temacie operowania na danych wejściowych, które mogą być prawidłowe, ale nie muszą.
Spotkałem się też z takimi mistrzami inżynierii, którzy we Free Pascalu (czyli technologii nie wspierającej GC), nigdy nie zwalniają dynamicznie alokowanej pamięci. Tzn. robią to tylko w trybie debug (zwalnianie opatrzone {$IFDEF}
-ami), aby heaptrc
nie wariował na koniec sesji ze zgłaszaniem co i gdzie wyciekło – zamykania komunikatów nie byłoby końca.
Po prostu program operuje na ograniczonej puli obiektów, przez co w teorii maksymalny łączny rozmiar wszystkich wycieków w danej sesji jest ograniczony, jednocześnie nie martwiąc się o wołanie Free
dla każdej dynamicznie tworzonej instancji. W końcu na koniec sesji, OS sam sprzątnie pamięć zużytą przez proces. Tak stworzony program działa ciut szybciej, o koder w teorii nie przejmuje się zwalnianiem czegokolwiek.
Dla mnie to rozwiązanie jest idiotyczne i niebezpieczne – dokłada tylko roboty, wydłuża kod (dodatkowe dyrektywy) i przy braku ostrożności, pamięć może cieknąć bez końca, a więc całkowicie wykrzaczyć aplikację. Nadmienię, że takie rozwiązanie jest wykorzystywane w jednym z większych projektów, AFAIR w sofcie dla placówek medycznych (ale nie pamiętam dokładnie). No ale są ludzie i parapety.