Schutzblöcke überflüssig!?

[freimatz]

Zitat von stahli:

Während der gesamten Laufzeit der Anwendung wird das Programm mit 99,99999%iger Sicherheit an diesen Stellen niemals eine Exception werfen.

Nein es sind nur 99,98%

Bei meinem Code sind schutzblöcke meistens unnötig - weil ich wo immer möglich Interfacereferencen verwende.
Ansonsten verwende ich die immer! Selbst wenn es technisch nicht nötig sein sollte, würde es meine Gewohnheit reduzieren, die dazu führt dass ich nicht mal einen vergesse.

[Ghostwalker]

Naja..so generell kann man das glaub ich nicht wirklich sagen, das Schutzblöcke überflüssig sind.
Es kommt wirklich auf die Situation drauf an.

Z.b. wenn ich auf den Source der Klasse, dich ich erzeugen möchte, keinen Zugriff hab (Stichwort: Komponenten von Dritt-Anbietern), dann kann ein Schutzblock nicht wirklich
schaden.

Wenn ich dagegen die Klasse selbst geschrieben hab, würd ich das eher weglassen, grad während der Entwicklung. Bei Entwicklungen im Team sie es wieder ganz anders aus.

Es gibt da denk ich viele Gründe für und gegen Schutzblöcke

[himitsu]

Zitat:

Entweder du behandelst die Exception oder du markierst deine Methode so, dass ....

Im XMLDoc/DocumentationInsight kann man zu erwartende Exceptions angeben, aber der Compiler beachtet sowas nicht.

Nur im HelpInsight wird dem Entwickler sowas dann angezeigt, falls er dort reinguckt.

Zitat:

Dein letzter Satz passt nicht. Vermisst Du sowas in Delphi?

Wenn er im Delphi ist, dann vermisst er das, was er von Java kennt.

Zitat:

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

Sowas kann man selbst teilweise behandeln.
Bei uns sind nahezu alle Komponenten abgeleitet.
Somit war es z.B. ein Leichtes in TTimer eine Behandlung einzufügen die nach x Fehlern den Timer disabled und eine letzte Fehlermeldung anzeigt, damit nicht millionen Fehlermeldungen aufploppen.

PS: Im OnPaint Fehlermeldungen anzuzeigen ist eine super Idee.
Fehler kommt und der wird angezeigt, Dialog ploppt auf, das Fenster bekommt spätestens beim Schließen des Dialogs mit, dass es neu gezeichnet werden muß und schon tritt der Fehler wieder auf ... Endlosschleife.
Hier also nur Loggen und/oder die Komponente auf Invisible stellen (und dannach notfalls das Programm beenden, bzw. das Fenster schließen).

[Delphi.Narium]

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

Und solange bleiben bei mir die Schutzblöcke drin.

Auch wenn ich von meinem Code (in Ausnahmefällen) absolut sicher sein kann, dass da keine Fehler drinne sind und ich von daher keine Fehler erwarte, bleiben die Schutzblöcke drinne, derweil: Auch mit meiner Erwartung kann ich gehörig schief liegen.

Bei jedem Objekt, dass ich erstelle, besteht die (theoretische) Möglichkeit, dass die Erstellung scheitert. Also muss das abgesichert werden. Und, egal welcher (erwartete oder unerwartete) Fehler auftritt, es spricht nichts dagegen, vorsorglich ein gesichertes Aufräumen zu implementieren.

Am schlechtesten sind die Fehler zu finden, die bei der unstrukturierten Behandlung von Fehlern in der Fehlerbehandlung auftreten, die nur deshalb passieren, weil man an der fehlerverursachenden Stelle vergaß (oder es fahrlässig für überflüssig hielt) für eine geordnete Weiterverarbeitung im Programm zu sorgen.

Oder ein ganz grober Vergleich:

Im Auto verzichtet man auch nicht auf das Anschnallen, den Airbag, die Knautschzone, nur weil man sicher ist, dass man gut und sicher autofahren kann und keinen Unfall baut.

Die Probleme kommen auch für 'nen perfekten Autofahrer häufig von außen.

Und bei Software sind dieses Außen z. B. Betriebssystem, Hardware, Compiler, Bios, (Anwender sollen zuweilen auch dazu gehören ), ..., die ggfls. auch (vermeintlich) fehlerfreie Software an den obskursten Stellen ins Straucheln bringen können. Und hier versuche ich durch 'ne (hoffentlich) vernünftige "Prophylaxe" möglichen Problemen aus dem Weg zu gehen.

Schutzblöcke gehören da selbstverständlich zu.

[freimatz]

Amen, Basta, ...

Zitat von stahli:

Mal eine ketzerische Behauptung...
Aber Schutzblöcke generell um Objekterzeugungen halte ich in den allermeisten Fällen für unnötig.

Doch noch eines: Ketzer werden heutzutage nicht mehr verbrannt, aber sie bekommen (zumindest bei mir) dafür Minuspunkte sollten sie sich um einen Job bewerben.

[stahli]

@Delphi.Narium

Wollen wir anhand Deines Beispiels mal weiter diskutieren?
Die Argumentation finde ich nämlich ganz passend. Vielleicht können wir ja irgendetwas draus ziehen...

Also das Beispiel mit dem Auto passt nicht ganz zu meinem Thema. Im Falle eines Unfalles helfen Gurt und Airbag, die Folgen zu mildern.
Bei der Software kann man die Analogie vielleicht bei einer Fehlerbeseitigung ziehen.
Die Funktion wird abgebrochen, der Speicherbereich wird aufgeräumt, der Anwender erhält eine Nachricht und kann mit einem konsistenten Datenbestand weiter arbeiten.
Soweit alles ok.


Was ich nicht nachvollziehen kann, ist folgendes:

Zitat von Delphi.Narium:

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

Und solange bleiben bei mir die Schutzblöcke drin.

...

Bei jedem Objekt, dass ich erstelle, besteht die (theoretische) Möglichkeit, dass die Erstellung scheitert. Also muss das abgesichert werden. Und, egal welcher (erwartete oder unerwartete) Fehler auftritt, es spricht nichts dagegen, vorsorglich ein gesichertes Aufräumen zu implementieren.

Am schlechtesten sind die Fehler zu finden, die bei der unstrukturierten Behandlung von Fehlern in der Fehlerbehandlung auftreten, die nur deshalb passieren, weil man an der fehlerverursachenden Stelle vergaß (oder es fahrlässig für überflüssig hielt) für eine geordnete Weiterverarbeitung im Programm zu sorgen.

...

Schutzblöcke gehören da selbstverständlich zu.

Nehmen wir noch ein konkretes Beispiel:

Wir erzeugen zwei Personenobjekte und überweisen einen Betrag.

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;

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.

Ob die Überweisung in der Datenbank realisiert wurde oder nicht, kann Dein Programm nicht nachvollziehen und der Anwender schon gar nicht.

Dass der Speicherplatz der zwei Objekte freigegeben wurde hilft auch niemandem - jedenfalls sehe ich dafür keinen sachlichen Grund.

Noch einmal: Eine Fehlerbehandlung und Benachrichtigung im Sinne "Überweisung ist fehlgeschlagen - bitte wiederholen! Der bisherige Datenbestand wurde nicht beeinträchtigt!" ist völlig korrekt. In dem Zusammenhang natürlich auch die Freigabe der erzeugten Objekte.


Aber alle Objektfreigaben in Schutzblöcke zu kapseln, ohne eine wirkliche Fehlerbehandlung zu realisieren - das halte ich für überflüssig.
Und oft wird ja so argumentiert, dass Objekte immer in Schutzblöcke gehören.

Ich sehe dafür einfach keinen sachlichen Grund.


@freimatz

Wenn man das so gewöhnt ist und machen möchte - ok.
Einen Nutzen sehe ich darin aber nicht (und habe auch noch kein überzeugendes Argument gehört).

[Delphi.Narium]

Hoffentlich hab' ich Dich nicht falsch verstanden.

Deine Argumentation klingt im Moment für mich in etwa so (sehr grob formuliert):

Wenn ich keine vernüftige Fehlerbehandlung habe, kann ich mir im Fehlerfalle auch die Freigabe von Objekten sparen.

Die Prozeduren bei Dir wären bei mir schonmal Funktionen, die im Erfolgsfalle ein True zurückgeben, im Fehlerfalle ein False. Wenn die erste Funktion fehlschlägt, wird die zweite nicht mehr ausgeführt. Welchen Sinn hätte es denn, wenn eine der beiden Personen nicht aus der DB geladen werden könnte, die Überweisung durchzuführen? Und dann das Ergebnis auch noch speichern?

Meiner Meinung nach ist Dein Beispiel schon logisch grob falsch, von daher halte ich anhand eines derartigen Beispiels eine Diskussion über die Sinnhaftigkeit von Schutzblöcken für nicht angebracht.

Oder mal wieder sehr dreist formuliert:

Wer so schlecht programmiert, kann sich auch Schutzblöcke sparen, die machen den Kohl dann auch nicht mehr fett.

Zitat von freimatz:

... aber sie bekommen (zumindest bei mir) dafür Minuspunkte sollten sie sich um einen Job bewerben.

Da würd' ich noch etwas weiter gehen: Hätten bei mir keine Chance, einen Job zu bekommen.

PS:

Das Autothema passt sehr gut.

Du argumentierst

Zitat:

Also das Beispiel mit dem Auto passt nicht ganz zu meinem Thema.

nämlich in der Begründung für das Nichtpassen im Zusammenhang mit Schutzblöcken, durch die Einführung von Schutzblöcken,

Zitat:

Im Falle eines Unfalles helfen Gurt und Airbag, die Folgen zu mildern.

dass es nicht passt.

Durch die Einführung dessen, dessen Nutzen Du bezweifelts, widerlegst Du ein Beispiel für den Sinn dessen, was Du bezweifelts?

Ehrlich gesagt: Auf so eine Diskussion hab' ich keine Lust.

[stahli]

Zitat von Delphi.Narium:

Deine Argumentation klingt im Moment für mich in etwa so (sehr grob formuliert):

Wenn ich keine vernüftige Fehlerbehandlung habe, kann ich mir im Fehlerfalle auch die Freigabe von Objekten sparen.

Die Prozeduren bei Dir wären bei mir schonmal Funktionen, die im Erfolgsfalle ein True zurückgeben, im Fehlerfalle ein False. Wenn die erste Funktion fehlschlägt, wird die zweite nicht mehr ausgeführt. Welchen Sinn hätte es denn, wenn eine der beiden Personen nicht aus der DB geladen werden könnte, die Überweisung durchzuführen? Und dann das Ergebnis auch noch speichern?

Meiner Meinung nach ist Dein Beispiel schon logisch grob falsch, von daher halte ich anhand eines derartigen Beispiels eine Diskussion über die Sinnhaftigkeit von Schutzblöcken für nicht angebracht.

...

Ehrlich gesagt: Auf so eine Diskussion hab' ich keine Lust.

Einmal kurz antworten will ich dennoch.

Wenn man (in möglichen Fehlerfällen) Rückgabewerte nutzt und den Programmablauf entsprechend steuert, ist das völlig in Ordnung (das Beispiel hatte ich ich auch gebracht). Das ist auch nicht der Ansatz, den ich kritisiert habe.

Ohne Fehlerbehandlung ist die Freigabe von Objekten im Fehlerfall nebensächlich - genau das UND NUR DAS meine ich.

[Delphi.Narium]

Zitat von stahli:

Ohne Fehlerbehandlung ist die Freigabe von Objekten im Fehlerfall nebensächlich - genau das UND NUR DAS meine ich.

deckt sich mit dem

Zitat von Delphi.Narium:

Wer so schlecht programmiert, kann sich auch Schutzblöcke sparen, die machen den Kohl dann auch nicht mehr fett.

Aber ehrlich: Ist eine Diskussion darüber, ob man bei schlechter bzw. fehlerhafter Programmierung Schutzblöcke nutzen soll oder nicht, wirklich zielführend?

[himitsu]

Zitat von Delphi.Narium:

Oder ein ganz grober Vergleich:

Im Auto verzichtet man auch nicht auf das Anschnallen, den Airbag, die Knautschzone, nur weil man sicher ist, dass man gut und sicher autofahren kann und keinen Unfall baut.

Es kommt nur auf die Definition drauf an.

In Deutschland kommt demnächst vermutlich ein neuer französischer Kleinstwagen auf den Markt
und dort wird kein Airbag eingebaut und für Knautschzone ist sowieso kein Platz ... du mußt dir nur eine passende Begründungen ausdenken, dann passt es schon.
* der ist so langsam, da passiert schon nichts
* und falls dir ein SUV oder LKW reinrauscht, dann ist eh alles egal

Das Ding ist unter Anderem auch für Jugendliche ab 16/17 Jahren gedacht (Motoradführerschein A1)
und die fahren bekanntlich sooo sicher und routiniert, dass da keine Unfälle zu erwarten sind.



Bezüglich Fehlerbehandlung oder Rückgaben auswerten
https://www.delphipraxis.net/205581-...ehandlung.html