Schutzblöcke überflüssig!?

[TiGü]

Einfach nur Nein!

[Daniel]

Würde ich auch sagen.

Wo soll man anfangen? Es gäbe so vieles, das man erwidern könnte...

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.

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

[stahli]

Zitat von Daniel:

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

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]

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:

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.

[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

[Jasocul]

Ich programmiere seit Turbo-Pascal 3.0 (und vorher mit Basic). Also ca. 40 Jahre.

Damals gab es keine Schutzblöcke und man musste einfach an alle möglichen Fehlerfälle denken. So programmiere ich auch heute noch. Dennoch ergeben Schutzblöcke Sinn. Es ist auch für den Anwender besser, wenn dieser eine sinnvolle Fehlermeldung bekommt und das Programm trotz einer Exception nicht abstürzt. Die Speicherlecks sind da meistens noch relativ unwichtig. Der Anwender wird froh sein, dass trotz eines Programmfehlers seine Bearbeitung mit dem Programm nicht verloren geht. Ohne Schutzblöcke sähe das völlig anders aus.

Ich denke, dass man es in beide Richtungen übertreiben kann.