Schutzblöcke überflüssig!?

**stahli**

Mobile Anwendungen - wenn auch nur eine Exception nach draußen zum Betriebssystem gelangt, ist das der Moment, in dem die App kommentarlos beendet wird. Als Entwickler mag man Werkzeuge haben, um die Logfiles einzusehen - der normale Anwender steht auf dem Schlauch.

Innerhalb eines Except- oder Finally-Blocks hast Du (je nach Situation) durchaus die Chance, die Anwendung wieder in einen kontrollierten und kontrollierbaren Zustand zu bringen und so zu retten. Deiner Aussage, dass eine Anwendung im Falle einer Exception grundsätzlich verloren ist, mag ich so pauschal nicht zustimmen.

Das ist ja etwas anderes. Eine Fehlermeldung auszugeben und eine Fehlerbereinigung (Datenbereinigung) durchzuführen ist ja in Ordnung.
Aber nur

markieren

Delphi-Quellcode:

			try

  ObjektErzeugen;

  EtwasTun;

finally

  ObjektFreigeben;

end;

Halte ich für unnütz. Da wird keine Fehlernachricht ausgegeben und keine Fehlerbehandlung durchgeführt (außer die Speicherfreigabe).

Allerdings weiß ich nicht, wie sensibel mobile Apps gehändelt werden müssen. Ich hatte nur Windowsanwendungen im Blick.

Zitat von hoika:

Hallo,

Zitat:

Folgender Code wird niemals einen Fehler produzieren:

Wenn der Code innerhalb der Methode (Methode2) eines Objektes ausgeführt wird, Beep eine Methode des Objektes ist und die anderen 3 Variablen ausserhalb des Objektes definiert sind, puhhhh

Dann
Wenn das Objekt nicht erzeugt wird, sondern nur Methode2 aufgerufen wird, schmiert der Code beim Beep ab.

So ganz kann ich jetzt nicht folgen. Aber solche Probleme würdest Du doch beim Testen Deiner Anwendung finden und bereinigen.
Wenn das oder das zutrifft ... das sind m.E. Kriterien, mit den die Anwendung umgehen können muss.
Wenn später Sonderfälle entdeckt werden, die noch unbehandelt sind, muss das natürlich nachgebessert werden. Aber ob die drei Objekte sofort mit dem Werfern der Exception aufgelöst werden oder nicht, macht doch keinen Unterschied.
Deine Anwendung läuft nach der Fehlermitteilung weiter und greift weiter auf die Speicherstellen zu, die noch die richtigen oder falsche Daten enthalten. Entweder läuft das Programm mit richtigen oder falschen Daten weiter oder es gibt weitere Exceptions.
Ich sehe da keinen Vorteil, dass die Speicher der drei Objekte zuvor freigegeben wurden.

Zitat von Der schöne Günther:

Zitat von stahli:

Natürlich gibt es auch Fälle, wo immer mit einem Problem gerechnet werden muss, dass man selbst nicht beeinflussen kann. Als Beispiel gäbe es da Erzeugen von Ordnern, Netzwerkunterbrechungen, Zugriffsfehler auf Dateien o.ä.

Falls es dich interessiert, schau mal wie das bei Java gelöst ist- Da kompiliert der Code gar nicht erst wenn du eine "zu erwartende" Exception nicht behandelst (z.B. Datei nicht gefunden usw.). Entweder du behandelst die Exception oder du markierst deine Methode so, dass man bei ihrer Benutzung ebendiese Exception zu erwarten hat. Und der Aufrufer deiner Methode muss es diese Exception dann behandeln.

Das vermisse ich an Java am meisten...

Das kenne ich nicht, klingt aber ganz gut. Es sind halt Sonderfälle, mit denen irgendwie umgegangen werden muss. Zumindest ist mit so etwas immer zu rechnen.

Dein letzter Satz passt nicht. Vermisst Du sowas in Delphi?
Soweit würde ich übrigens nicht gehen wollen. Wenn die Anwendung sicher stellt, dass z.B. ein Order "A" oder Ordner "B" erzeugt werden kann, dann muss man m.E. dafür keine Exceptionbehandlung erzwingen. Der Programmierer sollte aber aus eignem Interesse hier eine einrichten, wenn ein entsprechendes Problem vermutlich mal auftreten kann.

**Rollo62**

zusammenfalten · markieren

Delphi-Quellcode:

			procedure LebenswichtigeFunktion_SelfDriveCar_Ausweichmanöver;

begin

try

  ObjektErzeugen;

  EtwasTun;

finally

  ObjektFreigeben;

end; 

end;

...

...

...

procedure MainLoop;

begin

    while True

    begin

        if ObjektVoraus then

        begin

            LebenswichtigeFunktion_SelfDriveCar_Ausweichmanöver;

        end; 

    end; 

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 ?

**stahli**

Zitat von Rollo62:

markieren

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. Das könnte man als Sonderfall ansehen - wobei dann neben der Speicherfreigabe auch wieder eine echte Fehlerkorrektur erfolgen müsste, damit das Sinn macht.

Wie gesagt, es ging mir um reine Objektfreigabe im Finallyblock ohne Loop und ohne wirkliche Fehlerbehandlung.

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

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

zusammenfalten · markieren

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.

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

**TiGü**

Zitat von stahli:

zusammenfalten · markieren

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.

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