Schutzblöcke überflüssig!?

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

[Rollo62]

Zitat von stahli:

Zitat von Rollo62:

Delphi-Quellcode:

procedure MainLoop;
begin
...
            LebenswichtigeFunktion_SelfDriveCar_Ausweichmanöver;
...
end;

<== Wenn es crasht (z.B. out-of-memory) ohne try-finally fliegt es raus, OHNE Kontrolle
<== Mit try-finally hat man die Chance das es beim 2ten Mal noch funktiniert

Die Frage ist doch eher, wie wichtig ist die Sicherheit in deiner App ?

Das wäre so ein oben beschriebener Fall, dass im Sekundentakt neue Probleme auftauchen.

Eben nicht:
Das passiert nur EINMAL, nach 12 Jahren Betrieb ...

Wegen sowas stürzen Flugzeuge ab

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

[TiGü]

Zitat von stahli:

Delphi-Quellcode:

procedure Überweisung;
begin
  Person1 := TPerson.Create;
  Person1.LoadFromDB;
  Person2 := TPerson.Create;
  Person2.LoadFromDB;
  Person1.Überweise(Person2, 100);
  Person1.SaveToDB;
  Person2.SaveToDB;
  Person1.Free;
  Person2.Free;
end;

Bleiben wir mal bei diesem Beispiel von Seite 2.
Stelle dir vor, diese procedure läuft in einen Webserver bei einem Zahlungsdienstleister wie PayPal.

PayPal hat Millionen Kunden weltweit.

Jetzt nutzen 5000 Leute pro Stunde die Überweisungsfunktion.

Aus irgendeinen Grund schlägt LoadFromDB() oder Überweise() oder SaveToDB() fehl.
Der eigentliche Grund ist unerheblich.
Man kann es sich vorstellen, also wird es passieren.

Im schlimmsten Fall hast du dann 10000 TPerson-Instanzen pro Stunde, die dir den Speicher deines Webservers zumüllen.
Selbst unter 64-Bit ist dann durch Speicherfragmentierung irgendwann Schluss.

Ohne unhöflich sein zu wollen, aber da trennt sich wirklich die Spreu vom Weizen bzw. der Hobby-Programmierer vom Professional, der einfach schon zuviel (Schlimmes) gesehen hat und aus bitterer Erfahrung gelernt hat.

[stahli]

Ok, das ist ein gutes Beispiel und das kann ich auch nachvollziehen.

ABER: Dann muss allerdings auch eine Problembehandlung erfolgen und neben dem Freigeben der Objekte eine Fehlerbehandlung und Info an den Aufrufer erfolgen.

Dann passt das ja wieder.

Wenn aber nur die Objekte abgeräumt werden und der Aufrufer keinerlei Info erhält, dass etwas schief gelaufen ist, dann hat Paypal schnell ein echtes Problem.


Vielleicht habe ich die Beispiele, die man immer wieder sieht, wo also nur ein finally-Block ohne exception-Behandlung gezeigt wird, zu wörtlich genommen. Wenn damit immer auch eine Fehlerbehandlung verbunden wird, dann ist ja alles gut.

(Notfalls kann ich mal anhand eines kleines Demos und Videos den genaue Hintergrund meiner Frage noch besser verdeutlichen, wenn das jemand möchte.)

[jaenicke]

Zitat von stahli:

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

Wer sagt denn, dass es keine Fehlerbehandlung gibt? Die kann und sollte ja in den Aufrufen der Funktionen passieren.

Oder ganz anders:
Durch einen Buffer Overflow wird Speicher überschrieben und deshalb knallt es an einer ganz banalen Stelle, an der du ansonsten nie eine Exception vermuten würdest.

So etwas lässt sich dann leider auch nicht immer so schnell lösen, vor allem wenn es sich nicht um eine einfach vorhersagbare Speicherstelle handelt (auf die man dann einen Datenhaltepunkt setzen kann). Was ist dann besser? Ein Programm, bei dem Exceptions soweit möglich behandelt sind und durch Ressourcenschutzblöcke keine Speicherlecks auftreten, so dass es bis zu einer Lösung weitgehend normal weiter läuft, oder ein Programm, das man dann quasi gleich stilllegen kann bis eine Lösung gefunden ist, weil aufgrund des Fehlers der Speicher voll läuft?

Deine Vorstellung bezüglich des Ausschließens von Fehlern hört sich irgendwie so an als würdest du ausschließlich von relativ überschaubaren Programmen reden, an denen nur eine Person arbeitet. Bei größeren Programmen funktioniert diese ideale Vorstellung aber nun einmal nicht. Außer es handelt sich im so etwas wie einen Autopiloten, bei dem aber auch sehr viel mehr Ressourcen in die Qualitätssicherung gesteckt werden als bei normalen Programmen (hoffentlich ).

Oder anders:
Was wäre denn, wenn man bei dem Autopiloten deiner Logik folgen würde und sich darauf verlässt, dass keine unvorhersehbaren Fehler auftreten? Was, wenn dann doch ein Fehler passiert (siehe Tesla)? Soll man dann immer noch einfach sagen:

Zitat von stahli:

Bei einem unerwarteten Fehler arbeitet Dein Programm ohnehin nicht mehr sauber - das geht grundsätzlich nicht.

Dann schalten wir den Autopiloten einfach ab (weil es ja ohnehin nicht mehr sauber arbeitet) und das Auto, die Drohne oder die Marssonde knallen gegen das nächste Hindernis...

Unsere Anwendungen arbeiten auch nach unerwarteten Fehlern ggf. normal weiter. Es kommt nur darauf an wo ein Fehler auftritt. Das heißt nicht, dass solche Fehler dann nicht behoben werden müssen, aber man hat nicht direkt das Problem, dass vor Ort gar nichts mehr läuft.

[Delphi.Narium]

Zitat von stahli:

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.

Leider rufen aber nicht alle Kunden an oder erst, wenn sie durch wiederholen der zum Fehler führenden Funktion, quasi sichergestellt haben, dass da ein Fehler auftritt.

Und eine Beschwerde / Frage, ob de Daten noch sicher und in Ordnung sind, mag es ja geben, aber die Antwort muss immer sein: Ja die Daten sind sicher, die Daten sind in Ordnung. Wenn man da als Entwickler nicht sicher ist, dass man immer diese Antwort geben kann, hat man was falsch gemacht.

Ein Programm muss immer so geschrieben sein, dass auch bei einem schweren und unerwarteten Fehler, die Sicherheit der Daten garantiert ist. Auch dann noch, wenn der Anwender das Programm gegen alle Regeln der Vernunft weiter benutzt, neu startet und die zum Fehler führende Aktion wieder ausführt, das schlimmstenfalls mehrfach ...

Der größte Aufwand beim Programmieren ist nicht, richtigen und sauber funktionierenden Code zu schreiben und für eine korrekte Arbeit des Programmes zu sorgen, sondern sicherzustellen, dass bei allem davon abweichenden die Sicherheit und Korrektheit weiterhin garantiert ist.

Sprich: Die Fehlerbehandlung macht deutlich mehr Arbeit, als die eigentliche Progammlogik.

Und Schutzblöcke sind ein kleiner Teilbereich dessen.

@jaenicke
Jo, det isset.

Egal was in einem Programm an Fehlern passiert: Es läuft weiter und zwar ohne jegliche Einschränkung. Einen Fehler, der zu dem von stahli angesprochenen Szenario führt, dass es egal ist, ob man aufräumt oder nicht, darf es in Software für den professionellen Einsatz nicht geben Punkt. Und mindestens ein Dutzend Ausrufezeichen.

[stahli]

@jaenicke

Ja, meine Anwendungen sind recht überschaubar und ich arbeite allein daran.

Zitat von jaenicke:

Was ist dann besser? Ein Programm, bei dem Exceptions soweit möglich behandelt sind und durch Ressourcenschutzblöcke keine Speicherlecks auftreten, so dass es bis zu einer Lösung weitgehend normal weiter läuft, oder ein Programm, das man dann quasi gleich stilllegen kann bis eine Lösung gefunden ist, weil aufgrund des Fehlers der Speicher voll läuft?

Wenn durch den Fehler alle Konten der Bankkunden geleert wurden, wäre es besser, sofort abzubrechen und keine Daten mehr zu speichern. Wenn es sich um eine Zugriffsverletzung auf eine VCL-Komponente handelt, kann man erst mal problemlos weiter arbeiten.
Da es sich aber um völlig unerwartete Fehler handelt, für die man keine Behandlung vorgesehen hat, ist schwer zu sagen, was aktuell besser ist.


Mir ging es halt wirklich nur um solche Beispiele wie im Eingangspost, die man immer wieder überall findet.

Der Speicher läuft ja nicht gleich voll, wenn der Fehler einmal pro Monat aufläuft und das Programm ansonsten zuverlässig ohne Datenverlust funktioniert.
Dann kann man "in Ruhe" den Fehler bereinigen.

Wenn das Problem dagegen jede jede Minute auftritt (auch ohne Datenverlust) und nicht gleich gelöst werden kann und sonst den Speicher vollmüllt, dann kann man die Freigabe vielleicht in einen finally-Block setzten und die Fehlermeldung zunächst unterdrücken - bis man den Fehler vernünftig klären kann. Aber das wäre natürlich nur ein notfalls akzeptabler Workaround.

Solch einen ständig auftretenden Fehler würde man doch aber normalerweise schon in Tests finden und vermeiden, denke ich.


Ok, vielleicht sehe ich das zu optimistisch durch meine recht überschaubaren Projekte.


@Delphi.Narium

Dann können wir vielleicht zu dem Schluß kommen, dass das eingangs von mir besprochene Beispiel (das man immer wieder findet) tatsächlich nicht viel Wert hat, da dort keine Fehlerbehandlung erfolgt.

Mit Fehlerbehandlung ist das ja dagegen alles in Ordnung.

[freimatz]

Zitat von TiGü:

Einfach nur Nein!

Schutzblocke immer zu machen ist sinnvoll.

[Delphi.Narium]

Zitat von stahli:

Dann können wir vielleicht zu dem Schluß kommen, dass das eingangs von mir besprochene Beispiel (das man immer wieder findet) tatsächlich nicht viel Wert hat, da dort keine Fehlerbehandlung erfolgt.

Ja, solche Beispiel findet man immer.

Und man sollte sie als abschreckende Beispiele betrachten. Sie sind für den professionellen Einsatz sinnlos, kontraproduktiv, absolut ungeeignet.

Wenn ich mal was für mich programmiere oder nur 'ne schnelle Routine für 'ne einmalige Aufgabe, die nur ich nutze, spar' ich mir die Schutzblöcke auch. Aber das sind Routinen, die ich nur einmalig brauche, um was grundsätzlich auszuprobieren, einmalig 'ne Datei von Zustand A in den Zustand B zu bringen, ...

Aber wenn die Software von jemand anderem genutzt werden soll und das nicht nur einmalig, sondern dauerhaft im Geschäftsbetrieb, oder als dauerhaft nutzbares Hobbyprogramm, dann versuche ich das Programm so zu schreiben, dass es immer korrekt und sauber läuft, alles freigibt, immer verwertbare Fehlermeldungen ausgibt, und das auch noch in den Situationen, mit denen ich im Lebtag nicht gerechnet hätte, dass sie überhaupt möglich sein könnten. Selbst bei der Nutzung der Software vom größtmöglich denkbaren DAU, muss die Software noch sauber laufen. Und auch wenn im laufenden Betrieb Teile der Hardware abrauchen (Festplatte kaputt), verlustig gehen (Netzkabel gezogen, USB-Datenträger einfach mal eben so abgezogen), ..., muss bei professioneller Software die Datensicherheit garantiert werden können. (Hierunter fallen natürlich keine Datenverluste durch Hardwareschäden, aber die Daten auf 'nem vom Anwender einfach mal so abgezogenen USB-Datenträger, sollten konsistent bleiben.)