Aus: "FreeAndNil is often sign of wrong design - did anyone really read the blog?"
https://forums.embarcadero.com/threa...threadID=32623
Zitat:
Hence, Allen's assertion that, if calling FreeAndNil in a destructor
fixes your crash problems, there must be a design problem.
Frei übersetzt: "wenn man feststellt, dass man Crash-Probleme mit FreeAndNil im Destruktor in den Griff bekommt, dann ist das ein Hinweis auf ein Design-Problem".
Wenn man nun laufend solche FreeAndNil & Co. Absicherungen benötigt, weil die Entwickler sich nicht einig sind, wo das Problem - die Ursache der Crashs - liegt (oder es nicht verstehen), mag das ja gut sein um ein Softwareprodukt erst mal über Wasser zu halten. Es sollte aber dennoch versucht werden, die Ursache zu finden und durch geeignete Änderungen am Design in den Griff zu bekommen. Sonst rostet das Produkt unter dem Lack weiter vor sich hin, oder die vielen Tesafilm-Korrekturen die es zusammenhalten machen es immer schwieriger, es zu warten.
[man kann auch übermäßig defensiv programmieren und jede Zeile mit try ... except klammern (wobei im except Fall dann nichts getan wird). Das habe ich in Code schon gesehen und gefixt, der höllisch viele Exceptions erzeugte und daher entsprechend lahm lief]
Und, ja, es gibt Programmiersprachen die da robuster sind, aber manche von uns sind nun mal mit Delphi verheiratet
Cheers,