Schutzblöcke überflüssig!?

[freimatz]

Zitat von stahli:

Entweder weiß ich von vorn herein, dass an bestimmten Stellen ein Exception-Problem auftreten kann, das berücksichtigt werden muss oder ich merke es bei der Entwicklung bzw. in einer Testphase.

Da fallen mir nun wirklich nur ironische Kommentare ein.

Zitat von stahli:

Wenn ich 1000 Stellen im Code mit Schutzblöcken absichere und nur eine ein wirkliches Risiko beinhaltet, dann finde ich den Aufwand einfach nicht zu rechtfertigen (zumal der Code auch schlechter wartbar wird).

Wenn dem so wäre ja. Aber es ist nicht so. Es sind nicht 1000.
Ein Block ist in 5 Sekunden gemacht. Die Fehler oder Memory-Leak suchen, weil irgendein so ein mal gemeint hat auf einem Block verzichten zu können oder es vergessen hat, dauert teilweise Tage.

[Delphi.Narium]

Zitat von freimatz:

Zitat von stahli:

Entweder weiß ich von vorn herein, dass an bestimmten Stellen ein Exception-Problem auftreten kann, das berücksichtigt werden muss oder ich merke es bei der Entwicklung bzw. in einer Testphase.

Da fallen mir nun wirklich nur ironische Kommentare ein.

Habe schon viele Tester erlebt, richtig gute, die fanden Logikfehler durch passende Testdaten, auf die weder die Analysten noch die Entwickler je kamen.

Aber das die irgendwann mal ein Speicherleck gefunden haben, hab' ich nie erlebt.

[stahli]

Zitat von freimatz:

Da fallen mir nun wirklich nur ironische Kommentare ein.

Bitte bleib sachlich.

Wenn man z.B. mit Netzwerkverbindungen arbeitet muss man immer mit Abbrüchen rechnen und darauf reagieren.
An anderen Stellen wird aber doch mit getesteten Klassen und Bedingungen gearbeitet, wo keine Exceptions zu erwarten sind.
Wenn irgendwann doch Probleme erkannt werden, muss man eben doch nachbessern.

Das gehört für mich zu ordentlichen Tests.

Zitat von freimatz:

Ein Block ist in 5 Sekunden gemacht. Die Fehler oder Memory-Leak suchen, weil irgendein so ein mal gemeint hat auf einem Block verzichten zu können oder es vergessen hat, dauert teilweise Tage.

Ich sage ja nicht, dass Speicher nicht freigegeben werden soll. Im Falle dass "ES KNALLT" (man also einen schwerwiegenden Fehler hat, das Programm nicht mehr sauber funktioniert und beendet werden sollte und die (gespeicherten) Daten möglicherweise sogar kaputt sind) ist es wurscht, ob vor dem Crash Speicher von 3 Objekten freigegeben wurde oder nicht.
Wenn es ordentlich gerumst hat wirst Du bestimmt nicht schauen, ob der Speicher zuvor korrekt aufgeräumt wurde.
Du musst den Fehler finden und das Programm sowie die Daten bereinigen.

Wenn das Programm korrekt läuft, werden alle Free ausgeführt und es gibt kein Speicherleck.
Nur wenn es unerwartet Knallt, würde ein solches entstehen - aber dann hat man sowieso deutlich größere Probleme.
Mit einer Problemlösung ist auch das Speicherleck automatisch wieder vom Tisch.


Ich verstehe nicht, dass Du (weitestgehenden) Verzicht auf Schutzblöcke mit Gleichgültigkeit gegenüber Speicherlecks gleichsetzt.
Das hat doch gar nichts miteinander zu tun.

[Delphi.Narium]

Zitat von stahli:

Wenn man z.B. mit Netzwerkverbindungen arbeitet muss man immer mit Abbrüchen rechnen und darauf reagieren.
An anderen Stellen wird aber doch mit getesteten Klassen und Bedingungen gearbeitet, wo keine Exceptions zu erwarten sind.
Wenn irgendwann doch Probleme erkannt werden, muss man eben doch nachbessern.

Ich erwarte in meinen Programmen grundsätzlich keine Exceptions, schon garnicht nach ausreichenden Tests.

Die Schutzblöcke sind für die unerwarteten Fehler.

Wenn ich mit Netzverbindungen arbeite, dann wird dort, wo die Netzverbindung genutzt wird, eine Fehlerbehandlung implementiert, so dass von dort keine Exception "irgendwo ins Programm fliegen kann" und erst recht kein Programmzustand erreicht werden kann, bei dem eigentlich nur noch "ein Abschuß des Programmes" sinnvoll erscheint.

Zitat von stahli:

Wenn es ordentlich gerumst hat wirst Du bestimmt nicht schauen, ob der Speicher zuvor korrekt aufgeräumt wurde.
Du musst den Fehler finden und das Programm sowie die Daten bereinigen.

Das ist ein Zustand, der bei meinen Programmen nicht auftreten darf und ich kann mich nicht erinnern, wann so ein Zustand zuletzt aufgetreten ist. Das dürfte Jahre her sein (bezogen auf den Produktivbetrieb). Beim Entwickeln und Testen kann's schonmal passieren und dann weiß ich, dass ich meinen Hausaufgaben nicht vernünftig gemacht habe.

Zitat von stahli:

Wenn das Programm korrekt läuft, werden alle Free ausgeführt und es gibt kein Speicherleck

Stimmt, und mit Schutzblöcken kann ich mich sogar bei unerwarteten Fehlern darauf verlassen und nicht nur bei erwarteten.

Und ein Programm nach den Kriterien zu entwickeln, dass es im Extremfall egal ist, wenn was nicht freigegeben wird, ist mir zu kompliziert.

Meine Routinen sollen sowohl im Normalfall, als auch im Ausnahmefall, möglichst sauber arbeiten.

Aber irgendwie sind unsere Ansichten zu dem Thema sehr unterschiedlich. Also lassen wir es dabei.

[stahli]

Zwei Antworten möchte ich nochmal los werden (zum vielleicht besseren Verständnis):

Zitat von Delphi.Narium:

Das ist ein Zustand, der bei meinen Programmen nicht auftreten darf und ich kann mich nicht erinnern, wann so ein Zustand zuletzt aufgetreten ist. Das dürfte Jahre her sein (bezogen auf den Produktivbetrieb). Beim Entwickeln und Testen kann's schonmal passieren und dann weiß ich, dass ich meinen Hausaufgaben nicht vernünftig gemacht habe.

Genau das meine ich auch. Die Anwendung sollte so ausgerüstet sein, dass sie mit allen auftretenden Situationen umgehen kann.
Das muss sicher gestellt sein aber mehr ist nicht notwendig. Notfalls ist eine schnelle Nachbesserung erforderlich.

Zitat von Delphi.Narium:

Die Schutzblöcke sind für die unerwarteten Fehler.

...

Und ein Programm nach den Kriterien zu entwickeln, dass es im Extremfall egal ist, wenn was nicht freigegeben wird, ist mir zu kompliziert.
Meine Routinen sollen sowohl im Normalfall, als auch im Ausnahmefall, möglichst sauber arbeiten.

M.E. ist es einfacher, auf unnötige finally-Blöcke zu verziochten, wenn sie keinen tatsächlichen Nutzen haben.
Bei einem unerwarteten Fehler arbeitet Dein Programm ohnehin nicht mehr sauber - das geht grundsätzlich nicht.

Wenn es sich dagegen um ein erwartetes Problem handelt, das im Rahmen einer Exception behandelt und gelöst werden kann, dann ist es etwas völlig anderes - darum ging es mir aber nicht.


Insofern hat sich meine Einschätzung nicht geändert.
Aber danke für alle sachlichen Beiträge, auch wenn ich da mit der gängigen Einschätzung offenbar nicht überein stimme.


PS: Ich denke übrigens, dass ich ganz ordentlich und sauber programmiere (auch wenn ich kein Profi bin). Meine Programme laufen schon ganz zuverlässig und ohne Exceptions sowie die aktuelleren auch ohne Speicherlecks.

[himitsu]

Zitat von freimatz:

Ein Block ist in 5 Sekunden gemacht.

0.1 Sekunden

tryf[enter] oder trye[enter] oder über das Refactoring "umgeben"




An extremeinfachen oder zeitkritischen Stellen z.B. "geziehlt" keine Fehlerbehandlung zu machen würde ich als "Ausnahme" ansehen.
Das überdenkt man und schaut genauer hin und es wird an der Stelle dann auch dokumentiert, damit sich niemand wundet, weil dort was zu fehlen scheint.

[jaenicke]

Ich frage mich vor allem wo die Motivation eigentlich liegt. Leider sehe ich es viel zu oft, dass auf Kosten der Lesbarkeit (zu kurze Variablennamen) oder Wartbarkeit (with) ein paar geschriebene Zeilen oder Zeichen im Quelltext gespart werden (oder eben um ein paar Mikrosekunden an unwichtigen Stellen zu sparen wie bei try..finally weglassen). Zeichen im Quelltext zu sparen ist aber so ziemlich der unwichtigste Punkt, den es überhaupt gibt und die Performance im Bereich von try..finally ist auch meistens egal...

Viel wichtiger ist doch, dass der Code robust ist (eben nicht z.B. nach Änderungen plötzlich Speicherlecks verursachen kann), wartbar, lesbar ist usw., wofür es eben Konventionen zur Codeformatierung und aber auch zum Schreiben von Code in der jeweiligen Sprache gibt. Und dazu gehören in Delphi auch die Ressourcenschutzblöcke.

[stahli]

Zitat von jaenicke:

Ich frage mich vor allem wo die Motivation eigentlich liegt. Leider sehe ich es viel zu oft, dass auf Kosten der Lesbarkeit (zu kurze Variablennamen)...

Das hat mit meinem Anliegen/meiner Nachfrage nichts zu tun.

Zitat von jaenicke:

Viel wichtiger ist doch, dass der Code robust ist (eben nicht z.B. nach Änderungen plötzlich Speicherlecks verursachen kann)...

Eine bessere Robustheit erkenne ich durch einen finally-Block ohne wirkliche Fehlerbehandlung eben nicht. Aber das habe ich schon mehrfach erläutert.

Zitat von Rollo62:

Das passiert nur EINMAL, nach 12 Jahren Betrieb ...
Wegen sowas stürzen Flugzeuge ab

Um in dem Beispiel zu bleiben: Das Flugzeug stürzt bereits ab, aber die Piloten räumen vor dem Aufschlag schnell noch die Küche auf.

Wie gesagt, das Programm läuft normalerweise stabil und alle Objekte werden immer freigegeben.
Nach 1 Jahr tritt ein unerkannter Fehlerfall auf, der Kunde ruft an und beschwert sich über eine Fehlermeldung und fragt, ob seine Daten noch stimmen. Dann muss das Problem geklärt werden. Ob Person.Free noch durchlaufen wurde oder nicht, interessiert da nicht wirklich - nur welche Daten noch geändert und gespeichert wurden und wie sichergestellt werden kann, dass der Fehler nicht wieder auftritt.



Aber wir kommen da halt nicht zusammen. Lassen wir es dabei.
Es sehe es ja nicht als schädlich an, so zu arbeiten, nur halt als unnötig.