Dokumentation und Exceptions - Wann muss ich was erwarten?

[Namenloser]

Zitat:

Zitat von Der schöne Günther (Beitrag 1217629)

Dort finde ich:

Delphi-Quellcode:

try
   // Establish the connection.
   SQLConnection1.Connected := true;
   executeButton.Enabled := true;
   outputMemo.Text := 'Connection established!';
except
   on E: EDatabaseError do
      ShowMessage('Exception raised with message' + E.Message);
end;

Abgesehen davon, dass ich nicht einsehe, warum man die beiden Oberflächen-bezogenen Anweisungen nicht nach dem try-Block ausführen sollte

Naja, ganz einfach deshalb, weil die Ausführung nach dem except-Block ja ganz normal fortgesetzt wird. Da stünde dann „Connection established“, selbst wenn gar keine Verbindung aufgebaut werden konnte.

Ansonsten, da ich jetzt eine Weile mit Java arbeiten musste, gebe ich dir recht, dass Exceptions in Delphi besser dokumentiert sein könnten. Allerdings hatte ich in Delphi trotzdem nie Probleme damit (Ausnahme: Indy-Bibliothek, weil da einfach für alles eine Exception geworfen wird, selbst wenn es kein Fehler ist. Deshalb verwende ich die nicht mehr).

Wenn es dir wirklich nur darum geht, dass der Benutzer keine Fehler-Popups erhält, dann solltest du meiner Meinung nach einfach „Exception“ abfangen. Java-Checkstyle hat mir das nicht erlaubt, aber manchmal ist es nun mal wirklich genau das, was man will. Aber man sollte die Exception natürlich nicht einfach still schlucken, sondern an eine globale Fehlerbehandlungsmethode weiterleiten (z.B. zum loggen).

Oder unter Delphi gibt es noch eine weitere Möglichkeit, nämlich

Delphi-Quellcode:

TApplication.OnException

zu hooken. Das wäre sozusagen die letztmögliche Ebene, auf der eine Exception abgefangen werden kann, wenn alles andere versagt hat.

Die erste Methode kann trotzdem in manchen Situationen sinnvoll sein: Nehmen wir zum Beispiel mal an, dass unser Code alle Ordner rekursiv in einem Baum darstellen soll.

Delphi-Quellcode:

procedure VerzeichnisAuflisten(Verzeichnis: String);
begin
  for UnterVerzeichnis in Verzeichnis do
    VerzeichnisAuflisten(UnterVerzeichnis);
end;

Wenn jetzt ein Unterverzeichnis nicht eingelesen werden kann (aus welchem Grund auch immer), dann wollen wir ja wahrscheinlich trotzdem noch die anderen einlesen und nicht die ganze Operation abbrechen.

Delphi-Quellcode:

procedure VerzeichnisAuflisten(Verzeichnis: String);
begin
  try
    for UnterVerzeichnis in Verzeichnis do
      VerzeichnisAuflisten(UnterVerzeichnis);
  except
    on E: Exception do:
      Log(E);
  end;
end;

[Der schöne Günther]

Zitat:

Zitat von NamenLozer (Beitrag 1217659)

Naja, ganz einfach deshalb, weil die Ausführung nach dem except-Block ja ganz normal fortgesetzt wird.

Klar, im Exception-Fall hätte ich (wenn sinnvoll) dann auch die Methode verlassen. Aber das ist wohl persönlicher Stil.

Genau Java hat mir das auch mehr oder weniger angewöhnt, das ist bislang das einzige, was ich aus anderen Programmiersprachen wirklich in Delphi vermisse: Entweder man muss die Exception fangen, oder die Methode macht es mit dem Schlüsselwort

Delphi-Quellcode:

throws

explizit deutlich (und die aufrufende Methode muss es fangen).

Zitat:

Zitat von NamenLozer (Beitrag 1217659)

Oder unter Delphi gibt es noch eine weitere Möglichkeit, nämlich TApplication.OnException zu hooken

Klasse, das ist mir viel wert! :thumb:

[mjustin]

Zitat:

Zitat von NamenLozer (Beitrag 1217659)

Ansonsten, da ich jetzt eine Weile mit Java arbeiten musste, gebe ich dir recht, dass Exceptions in Delphi besser dokumentiert sein könnten. Allerdings hatte ich in Delphi trotzdem nie Probleme damit (Ausnahme: Indy-Bibliothek, weil da einfach für alles eine Exception geworfen wird, selbst wenn es kein Fehler ist. Deshalb verwende ich die nicht mehr).

Ein weit verbreiteter Irrtum: Exceptions mit Fehlern gleichzusetzen. Exception heisst übersetzt nur "Ausnahme", und das trifft ihren Zweck besser - sonst würden sie "Error" heissen.

Eine Exception ist nicht mehr als eine Ausnahme vom erwarteten, regulären Programmablauf. In der richtigen Dosis eine enorme Hilfe, da man mit ihnen leichter lesbaren Code schreiben kann, vor allem wenn Fehler in unteren Ebenen der Verarbeitung auftreten können.

Ohne Exceptions wäre eine Behandlung der Fehler, die in tieferen Schichten (Bibliotheken und deren Unter-Bibliotheken) auf Anwendungsebene nur möglich, wenn man alle denkbaren Fehlercodes in Rückgabeparametern an den eigenen Code hochreicht.

Wenn man sich von der Vostellung "Exception = Fehler" löst, ist Indy eher ein Beispiel für elegante und sinnvolle Nutzung von Exceptions.

EProgrammerNotFound ist eher ein Negativbeispiel ;)

[Der schöne Günther]

Ja, die wird bei mir immer geworfen wenn ich im Urlaub bin. :stupid:

Das sehe ich auch so. Exceptions setze ich gerne ein und habe auch nichts dagegen, an allen Ecken und Enden auf die verschiedensten Dinge reagieren zu können.

Nur es muss einem bitte auch jemand sagen, was wo auftreten kann. Sonst kann einem das wirklich alles durcheinander würfeln. Das gleiche Problem hatte ich bei einem kurzen Spiel mit Indy auch: Nichts gegen Werfen von Exceptions an allen möglichen Stellen. Aber diese Stellen muss man auch ohne eine halbe Stunde Nachbohren erkennen können.

[Uwe Raabe]

Es gibt halt Exceptions, die können immer auftreten, z.B. die von EExternal abgeleitet sind oder auch EOutOfMemory. Diese Exceptions werden ja nicht explizit im Programmcode ausgelöst, sondern entstehen auf Grund einer unerwarteten Umgebungsbedingung. In manchen Fällen kann man diese Exceptions durch vorheriges Prüfen vermeiden. Trotzdem muss man immer damit rechnen. Schließlich ist niemand unfehlbar. Es macht aber wenig sinn, jede potentiell gefährliche Code-Zeile mit einem try-except-Block zu schützen und alle denkbaren Exceptions abzufangen (wobei oft fraglich ist, was dann geschehen soll). Damit wäre der Vorteil von Exceptions ad absurdum geführt.

Wenn der User schon keine dieser Exceptions zu sehen bekommen soll, dann bietet sich Application.OnException sicher an. Ich würde dann aber gleich ein Tool wie madExcept einsetzen, das mir in dem Fall auch noch alle nötigen Informationen zur Verfügung stellt.

[Der schöne Günther]

maxExcept. Faszinierend.

Wieder was Neues kennen gelernt, das sieht nett aus. Danke dafür.


Nur wie gesagt: Klar gibt es Dinge, die man einfach nicht vorhersehen kann. Mein eingangs genanntes Beispiel ist aber vollkommen offensichtlich: Die Datenbankverbindung schlägt fehl, das Ding wirft eine Exception. Das ist vollkommen vorhersehbar. Die Dokumentation lässt das vollkommen unter den Tisch fallen, und ich finde das ein absolutes Unding. Wahrscheinlich macht mich auch nur diese schreckliche Hitze so aggressiv... :roll:

[Namenloser]

Zitat:

Zitat von mjustin (Beitrag 1217680)

Ein weit verbreiteter Irrtum: Exceptions mit Fehlern gleichzusetzen. Exception heisst übersetzt nur "Ausnahme", und das trifft ihren Zweck besser - sonst würden sie "Error" heissen.

Eine Exception ist nicht mehr als eine Ausnahme vom erwarteten, regulären Programmablauf.

Ja, aber sowas wie „Connection closed gracefully“ ist nun wahrlich keine „Ausnahme“.

Indy hat mich schier in den Wahnsinn getrieben, weil ich in jeder Methode hundert „Ausnahmen“ abfangen musste, die den Programmablauf in keinster Weise beeinflusst hätten, wenn Indy nicht durch die Exception selbst das Programm fünf Aufrufs-Ebenen weiter oben unnötig zum Abschmieren gebracht hätte.

Es ist vielleicht Geschmackssache, aber ich fand Synapse deutlich angenehmer zu benutzen.

[sahimba]

Zitat:

Zitat von NamenLozer (Beitrag 1217690)

Ja, aber sowas wie „Connection closed gracefully“ ist nun wahrlich keine „Ausnahme“.

EAbort ja auch nicht "wirklich". Trotzdem hat EAbort seine Berechtigung. „Connection closed gracefully“ ist quasi das Jedi-Äquivalent zu EAbort. Aus dem Grunde kann man auch im Debugger Exceptionklassen festlegen, welche ignoriert werden. Diese "stillen" Exceptions sollte man sinnvollerweise in seiner Anwendung dann ebenso auf oberer Ebene filtern.