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