Schutzblöcke überflüssig!?

**Delphi.Narium**

Der verlinkte Thread zeigt ja, dass es diverse Ursachen für

Zitat:

Der wissenschaftliche Beweis, dass man fehlerfreie Software schreiben kann, steht noch aus.

gibt.

Man kann selbst noch so gut, gewissenhaft, sicher und (hoffentlich) fehlerfrei programmieren. Man weiß nun mal nicht, ob die genutzten Bibliotheken, Compiler, ... absolut fehlerfrei sind, ob alle genutzen Betriebssystemfunktionen fehlerfrei sind, ...

Also wird versucht das "eigene Zeugs" so zu schreiben, dass man bei allen Fehlern, bei denen man erahnt, dass sie passieren könnten, eine sichere Fehlerbehandlung, eine sichere Freigabe von Resourcen, ... implementiert.

Und ja: Die Implemetierung all dessen ist aufwändig, wenn man Pech hat macht's sogar den größten Teil der Programmierung aus.

**jaenicke**

Zitat von stahli:

Hier können jetzt diverse Probleme auftreten.
Wenn man die zwei Free-Anweisungen jetzt in einen Finally-Block setzt - ohne sonstige Fehlerbehandlung - findest Du weder den Fehler besser noch ist Dein Datenbestand besser geschützt noch erhält der Anwender bessere Fehlerinformationen.
Nur der Speicherplatz der zwei Objekte wird wieder freigegeben. Der Aufrufer der Prozedur Überweisung weiß nichts von dem Fehler und das Programm geht davon aus, dass alles passt.

Doch, denn es geht ja um den Fall, dass eine Exception ausgelöst wird, so dass die Freigabe des Objekts übersprungen würde, weil man bei der Exception heraus springt. Dann kann die Exception zwar abgefangen werden, aber der Speicher wird nicht freigegeben.

Und nun nehmen wir mal an der Code wird in einem Programm immer wieder aufgerufen, das länger läuft, z.B. ein Webservice... da ist dann irgendwann trotz sauberer Behandlung der Exceptions der Speicher voll.

Wenn es nur um wenige Aufrufe geht, merkt man in der Tat nicht viel davon. Aber das Programm benutzt eben mehr Speicher als nötig.

Noch schlechter wird es, wenn man in dem Objekt ein Handle auf eine Datei offen hat oder ähnliches, so dass die Datei dann gesperrt bleibt bis das Programm beendet wird.

Und damit man das nicht immer neu bewerten muss, macht es Sinn einfach immer eine korrekte Behandlung solcher potentiellen Probleme einzubauen. Denn sonst müsstest du ja bei jeder Änderung schauen, ob deine Prozedur nicht irgendwo aufgerufen wird, wo dann eine Behandlung nötig wird...

Davon abgesehen bringt ein Ressourcenschutzblock nur etwas, wenn er auch korrekt aufgebaut ist (Konstruktoraufruf vor dem try, sonst springt man bei einer Exception im Konstruktor auch in das finally obwohl die Variable noch gar nicht zugewiesen ist und dann knallt es ggf. dort erneut):

zusammenfalten · markieren

Delphi-Quellcode:

			procedure Run;

begin

  obj1 := TObject.Create;

  try

    Beep;

    obj2 := TObject.Create;

    try

      obj3 := TObject.Create;

      try

        Beep;

      finally

        obj3.Free;

      end;

    finally

      obj2.Free;

    end;

  finally

    obj1.Free;

  end;

end;

try

  Run;

except

  on E: Exception do

  begin

    WriteLog(E);

    UserDialog(Format('Interner Fehler: %s - %s', [E.ClassName, E.Message]));

  end;

end;

**himitsu**

Zitat von jaenicke:

Konstruktoraufruf vor dem try, sonst springt man bei einer Exception im Konstruktor auch in das finally obwohl die Variable noch gar nicht zugewiesen ist und dann knallt es ggf. dort erneut

Man könnte jetzt zwar denken
"ist doch nicht so schlimm, wenn es nochmal knallt ... der Nutzer bekommt ja dennoch nur einen Fehler zu sehen"
aber das stimmt nicht, denn er und ein eventuelles Logging bekommt nur den letzten Fehler zu sehen und die "eigentliche" Fehlermeldung und Position ist dann weg, was echt blöd für die Fehlersuche ist.
Das ist genauso schlimm, wie wenn man im Except den Fehler abfängt und den Fehlertext durch einen sinnlosen und nichtssagenden Text ersetzt.

Und da die Vairale nicht initialisiert ist, kann sie sonstwo hinzeigen,
wodurch dann das Free nochmal richtig was im Speicher zerstören kann, und somit die Funktion seines Programm dann richtig schädigen würde.

**stahli**

Ja, danke Sebastian.

Deinen Text kann ich nachvollziehen und da gehe ich auch weitestgehend mit.
Dein Beispiel ist grundsätzlich auch in Ordnung, da Du eine Exception auswertest und darauf reagierst.

Oft sieht man aber Beispiele wie Dein "Run" alleinstehend, wo die Objekte wieder freigegeben werden und keine Fehlerbehandlung ersichtlich ist.
Das finde ich dann halt unsinnig.

Folgenden Punkt Deiner Ausführungen sehe ich aber dann doch anders:

Zitat von jaenicke:

Und damit man das nicht immer neu bewerten muss, macht es Sinn einfach immer eine korrekte Behandlung solcher potentiellen Probleme einzubauen. Denn sonst müsstest du ja bei jeder Änderung schauen, ob deine Prozedur nicht irgendwo aufgerufen wird, wo dann eine Behandlung nötig wird...

Ich finde den Ansatz sinnvoller, mich dabei auf die potenziell problematischen Stellen zu beschränken.
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.
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 das mögliche Problem in Deinem Beispiel nicht vermeidbar ist (z.B. Netzkabel gezogen) und Deine Exceptionbehandlung das Problem vollständig löst, so dass das Programm korrekt mit konsistenten Daten weiter arbeitet, dann ist die Lösung absolut sinnvoll.
Eine Datenbereinigung ist dort jedoch auch nicht skizziert, sondern nur ein Log und eine Infobox.

Wenn KEINE ausdrückliche Datenbereinigung erfolgt, dann muss vor einer Fortsetzung der Arbeit erst mal der Datenbestand gesichert/geprüft und der Fehler in der Software schnell bereinigt werden.
In dem Moment komme ich wieder zu dem Schluss, dass die finallys in dem Run völlig verzichtbar sind:

Dein Code wäre dann m.E. gleichwertig zu folgendem:

zusammenfalten · markieren

Delphi-Quellcode:

			procedure Run;

begin

  obj1 := TObject.Create;

  Beep;

  obj2 := TObject.Create;

  obj3 := TObject.Create;

  Beep;

  obj3.Free;

  obj2.Free;

  obj1.Free;

end;

try

  Run;

except

  on E: Exception do

  begin

    // VollständigeDatenprüfungUndBereinigung;

    WriteLog(E); 

    UserDialog(Format('Interner Fehler: %s - %s', [E.ClassName, E.Message]));

  end;

end;

Hier mal angenommen, der Fehler wäre nicht komplett ausgebügelt und der Datenbestand möglicherweise inkonsistent.
In beiden Fällen erhalten wir eine Info und einen Log aber wir wüssten nicht, was nun mit den Daten ist.
Der Fehler müsste bereinigt werden und das Programm ein Update erhalten.
Eine Weiterarbeit wäre dem Anwender nicht zu empfehlen, weil wir nichts über den Datenbestand sagen können.
Die verkürzte Run-Prozedur hätte keine wirklichen Nachteile gegenüber Deiner. Ok, da dümpeln noch 1 - 3 Speicherbereiche im Speicher rum, aber das Programm muss ja sowiso beendet werden.

Wenn da natürlich die VollständigeDatenprüfungUndBereinigung eingebaut wäre, dann wäre Deine Lösung perfekt und absolut richtig.

Fazit:
- Exceptionbehandlung mit Datenbereinigung -> Object.Free im Finally sinnvoll
- keine Exceptionbehandlung mit vollständiger Datenbereinigung -> Object.Free im Finally nicht hilfreich

Und vollständige Datenbereinigung bei möglichen Fehlern kann man nur bei erwarteten bzw. denkbaren Fehlern durchführen.

**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.