Dokumentation und Exceptions - Wann muss ich was erwarten?

[Der schöne Günther]

Das ist schon das (mindestens) dritte Thema zum Bereich Exceptions, ich werde irgendwie immer noch nicht warm damit, wie Exceptions in der Delphi-Welt generell gehandhabt werden.

Dass auf meine generelle Frage http://www.delphipraxis.net/173885-w...exception.html keine eindeutige Antwort existiert ist natürlich verständlich. Mein jetziges Anliegen ist stark verwandt mit meiner unbeantworteten Frage http://www.delphipraxis.net/174454-u...ns-finden.html :

Ich schaue mir fröhlich von Embarcadero Tutorial: Herstellen einer Verbindung zu einer SQLite-Datenbank (Delphi) an.

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: Woher kann ich wissen, dass ich einen

Delphi-Quellcode:

EDatabaseError

zu erwarten habe?

Die Dokumentation erzählt weder bei TSQLConnection::Connected noch TCustomConnection::Connected von einer möglichen Exception. Immerhin spricht sie von einer intern aufgerufenen Methode TCustomConnection.DoConnect. Doch auch hier: Kein Sterbenswort.

Und auf Dauer habe ich ehrlich gesagt auch nicht die Zeit, in Methoden wie

Delphi-Quellcode:

TSQLConnection.DoConnect

zu suchen, was denn hier alles Exceptions nach oben werfen könnte:

Delphi-Quellcode:

procedure TSQLConnection.DoConnect;
var
  ConnectionProps: TDBXProperties;
  Ind: Integer;
  ConnectionFactory: TDBXConnectionFactory;
  LoginParams: TStrings;
  SchemaOverride: string;
  SchemaOverrideList: TStringList;
  Password: string;
  MemoryConnectionFactory: TDBXMemoryConnectionFactory;
begin
  ConnectionProps   := nil;
  LoginParams := TStringList.Create;
  MemoryConnectionFactory := nil;
  try
    if LoadParamsOnConnect then
    begin
      ConnectionFactory := TDBXConnectionFactory.GetConnectionFactory;
      TDBXConnectionFactory.Lock;
      try
        ConnectionProps   := ConnectionFactory.GetConnectionProperties(ConnectionName);
        ConnectionProps   := ConnectionProps.Clone;
      finally
        TDBXConnectionFactory.Unlock;
      end;
    end else
    begin
      ConnectionProps   := TDBXProperties.Create;
      try
        ConnectionFactory := TDBXConnectionFactory.GetConnectionFactory;
      except
        MemoryConnectionFactory := TDBXMemoryConnectionFactory.Create;
        ConnectionFactory := MemoryConnectionFactory;
        ConnectionFactory.Open;
      end;
      ConnectionProps.AddProperties(FParams);
      if ConnectionProps.Properties.IndexOfName(TDBXPropertyNames.DriverName) = -1 then
        ConnectionProps.Add(TDBXPropertyNames.DriverName, DriverName);
    end;
    CheckLoginParams;
    ConnectionState := csStateConnecting;

    GetLoginParams(LoginParams);
    if LoginParams.Values[TDBXPropertyNames.Database] <> ConnectionProps[TDBXPropertyNames.Database] then
    begin
      ConnectionProps[TDBXPropertyNames.Database] := LoginParams.Values[TDBXPropertyNames.Database];
    end;

    SetCursor(HourGlassCursor);

    ConnectionProps.Add('UNLICENSED_DRIVERS', IntToStr(GDAL)); // Do not translate.

    FLoginUsername := LoginParams.Values[TDBXPropertyNames.UserName];
    if FLoginUserName <> '' then
      ConnectionProps[TDBXPropertyNames.UserName] := FLoginUsername;
    Password := LoginParams.Values[TDBXPropertyNames.Password];
    if Password <> '' then
      ConnectionProps[TDBXPropertyNames.Password] := Password;
    ConnectionProps.SetComponentOwner(self);
    ConnectionProps.Events.Events[sValidatePeerCertificate] := TEventPointer(ValidatePeerCertificate);

    ConnectionFactory.Lock;
    try
      FDBXConnection := ConnectionFactory.GetConnection(ConnectionProps);
    finally
      ConnectionFactory.Unlock;
    end;

    for Ind := 0 to FMonitorUsers.Count -1 do
      FMonitorUsers[Ind].UpdateTraceCallBack;

    SetCursor(HourGlassCursor);

    RegisterTraceCallback(True);

    FDefaultSchema := '';

    if (FDBXConnection.ProductName = 'BlackfishSQL') then {Do not localize}
    begin
      FDefaultSchema := 'DEFAULT_SCHEMA'; { Do not localize }
    end;

    SchemaOverride := ConnectionProps[TDBXPropertyNames.SchemaOverride];

    if (SchemaOverride = '') and LoadParamsOnConnect then
    begin
      TDBXConnectionFactory.Lock;
      try
        SchemaOverride := ConnectionFactory.GetDriverProperties(ConnectionProps[TDBXPropertyNames.DriverName])
                          [TDBXPropertyNames.SchemaOverride];
      finally
        TDBXConnectionFactory.Unlock;
      end;
    end;

    if SchemaOverride <> '' then
    begin
      SchemaOverrideList := TStringList.Create;
      try
        SchemaOverrideList.Delimiter := '.';
        SchemaOverrideList.DelimitedText := SchemaOverride;
        if SchemaOverrideList.Count = 2 then
        begin
          if (SchemaOverrideList[0] = '%') or (SchemaOverrideList[0] = FLoginUsername) then
            FDefaultSchema := SchemaOverrideList[1];
        end;
      finally
        SchemaOverrideList.Free;
      end;
    end;

    ConnectionOptions;

    ConnectionState := csStateOpen;
  finally
    FreeAndNil(MemoryConnectionFactory); // If allocated, free it.
    SetCursor(DefaultCursor);
    LoginParams.Free;
    ConnectionProps.Free;
    if ConnectionState = csStateConnecting then // an exception occurred
    begin
      ConnectionState := csStateClosed;
      if Assigned(FDBXConnection) then
        FreeAndNil(FDBXConnection)
    end;
  end;
end;

Deshalb: Irgendwoher muss die Doku ja die Weisheit nehmen, dass irgendwoher ein

Delphi-Quellcode:

EDatabaseError

kommen kann. Ich bin zu dumm, das zu sehen. Bitte helft mir.

[Lemmy]

Zitat:

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

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

Delphi-Quellcode:

EDatabaseError

zu erwarten habe?
....
Deshalb: Irgendwoher muss die Doku ja die Weisheit nehmen, dass irgendwoher ein

Delphi-Quellcode:

EDatabaseError

kommen kann. Ich bin zu dumm, das zu sehen. Bitte helft mir.

ist doch ganz einfach: Du weißt das aus der Dokumentation - in diesem Fall aus dem entsprechenden Codebeispiel.

Der Doku-Schreiber weiß, dass da ein EDatabaseError aufschlagen kann (so lange er keinen Fehler gemacht hat) vom Entwickler, der die betreffende Bibliothek geschrieben hat, und der sollte das eigentlich wissen.

Zitat:

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

was denn hier alles Exceptions nach oben werfen könnte:

das ist eigentlich Aufgabe der Dokumentation, das zu beschreiben...

Grüße

[Der schöne Günther]

Ein "So basteln Sie sich eine XYZ-Anwendung"-Tutorial das ich zufällig über Google gefunden habe ist doch keine Dokumentation :evil:, auch wenn es von Embarcadero stammt. Finde ich.

Würde es in der Doku angesprochen werden, würde ich das noch vielleich gelten lassen. Aber das steht einfach nur so im Raum. Woher weiß ich, was noch für Arten von Fehlern nach oben geworfen werden können? Ich möchte nicht dort enden, aus Unwissenheit grundsätzlich Exceptions zu essen, nur weil Embarcadero nichts vernünftig dokumentiert hat (falls das denn der Fall sein sollte)...

[Bummi]

Wichtig scheint mir das nur wenn Du auf verschiedene Exceptions unterschiedlich reagieren willst, was dann ja voraussetzt dass Du weist was Du wie behandeln will. Den Rest kannst Du ja über den else Zweig abfackeln.

Delphi-Quellcode:

procedure Tuwas(const s:String);
var
   i:Integer;
begin
  try
    i := StrToInt(s);
    Showmessage(FloatToStr(1/i));
  except
    ON E:Exception do
    begin
      if E is EZeroDivide then Showmessage('Divison durch 0')
      else Raise;  // oder was  auch sonst hier vorzusehen wäre
    end;
  end;
end;

procedure TForm3.Button1Click(Sender: TObject);
begin
  TuWas('0');
  TuWas('Nase');
end;

[Lemmy]

Zitat:

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

Ein "So basteln Sie sich eine XYZ-Anwendung"-Tutorial das ich zufällig über Google gefunden habe ist doch keine Dokumentation :evil:, auch wenn es von Embarcadero stammt. Finde ich.

Kannst Du blöd finden oder nicht, ändert aber nichts daran, dass es die offizielle Doku ist.

Zitat:

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

Ich möchte nicht dort enden, aus Unwissenheit grundsätzlich Exceptions zu essen, nur weil Embarcadero nichts vernünftig dokumentiert hat (falls das denn der Fall sein sollte)...

wo isst Du Exceptions? Du reagierst auf EDatabaseError und der Rest wird an die gui geworfen (ist zumindest bei Delphi 7 so und wird auch hoffentlich in XEx nicht anders sein)

[Der schöne Günther]

Zitat:

Zitat von Bummi (Beitrag 1217637)

Wichtig scheint mir das nur wenn Du auf verschiedene Exceptions unterschiedlich reagieren willst

Vollkommen richtig.

Ich möchte ja nur überhaupt wissen, dass da etwas kommen kann! Meine Beschwerde ist bislang nur:

"Zufällig sah ich in diesem zusammenhangslosen Tutorial, dass diese Methode eine Exception werfen kann. Das steht weder in der Doku, noch ist es in der Implementation ersichtlich. Das darf nicht sein, Embarcadero!"

Weiterhin die Hoffnung, dass die Beschwerde unbegründet ist.

Zitat:

Zitat von Lemmy (Beitrag 1217638)

Kannst Du blöd finden oder nicht, ändert aber nichts daran, dass es die offizielle Doku ist.

Meinetwegen. Aber selbst das ist nicht vollständig. Das Teil kann genauso gut eine TDBXError-Exception werfen. Und die ist mit dem EDataBaseError nicht verwandt. Die fängt der Kerl in seinem Tutorial auch nicht. Und in der Doku vermerkt ist es natürlich auch nicht.

[sahimba]

Zitat:

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

Witzigerweise kann das Ding auch noch ganz andere Exceptions werfen. Und die fängt der Tutorialersteller nicht.

Man "sollte" imho auch nur jene Exceptions behandeln, auf welche man auch wirklich (sinnvoll) reagieren kann. Im Zweifel lässt man sie eben ganz nach oben bubbeln.

Wobei es immer Ausnahmen von der Regel gibt und auch selten, ganz selten, ein Exceptionhandler sinnvoll sein kann, welcher wirklich alles schluckt. An dem Thema entzündeten sich fraglos schon Religionskriege.

[Der schöne Günther]

Zitat:

Zitat von sahimba (Beitrag 1217640)

Im Zweifel lässt man sie eben ganz nach oben bubbeln.

Ja, das ist der springende Punkt. Die Delphi-Welt ist für mich immer noch relativ neu, das scheint sich ja wirklich eine gängige Methode zu sein. Da möchte ich auch nichts gegen sagen, aber in meinem Projekt ist das absolut keine Option. Es darf nicht sein, dass irgendwo vielleicht doch noch bis an den Benutzer irgendeine Systemmeldung "Datenbanktreiber versagt beim Zugriff auf XYZ: Fehlercode 723" durchgereicht wird.

[Lemmy]

Zitat:

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

Dass auf meine generelle Frage http://www.delphipraxis.net/173885-w...exception.html keine eindeutige Antwort existiert ist natürlich verständlich.

ich habe dir da 2 Links angehängt, vielleicht helfen die dir weiter, oder ggf. kennst Du die schon.

Zitat:

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

Zitat:

Zitat von sahimba (Beitrag 1217640)

Im Zweifel lässt man sie eben ganz nach oben bubbeln.

Ja, das ist der springende Punkt. Die Delphi-Welt ist für mich immer noch relativ neu, das scheint sich ja wirklich eine gängige Methode zu sein.

Was ist denn die Alternative? Du reagierst auf Exceptions wenn:
1. du sicher stellen musst, dass gewisse Anweisungen immer bearbeitet werden (try-finally)
2. bei erwarteten Fehlern (Datei nicht gefunden, Passwort nicht eingegeben) ein alternativer Programmzweig aufgerufen wird, der dem Anwender die Möglichkeit bietet zu reagieren oder um den Fehler zu loggen und für eine spätere Korrektur vorzumerken
...

[sx2008]

Also ein Code wie dieser macht überhaupt keinen Sinn:

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;

1. Problem:
der Programmfaden läuft weiter obwohl das Öffnen der Datenbank erfolglos was.
In der Folge wird es im weiteren Verlauf zu einer weiteren Exception kommen.
2. Problem:
das Abfangen der Exception und das

Delphi-Quellcode:

ShowMessage

vernichtet wichtige Informationen zur Fehlersuche.
Es geht z.B. die genaue Exception-Klasse verloren.
Die Fehlermeldung "Exception raised with message" ist absolut Aussagelos, es steckt keine nützliche Information drin.
3. Problem:
durch das Abfangen der Exception, geht die Möglichkeit verloren die Exception automatisch in eine Logdatei zu schreiben.

Wie macht man es dann richtig?
1. Regel:
Exceptions nur dann abfangen, wenn man irgendwas zur Verbesserung beitragen kann.
Die Idee man könnte eine Exception durch abfangen irgendwie "reparieren" ist sowieso in 99% aller Fälle falsch.
Was man allerdings tun kann ist dem Benutzer möglichst gute Informationen zu geben was die Ursache b etrifft und wie er das Problem beheben kann.

Delphi-Quellcode:

try
   // Establish the connection.
   SQLConnection1.Connected := true;
   executeButton.Enabled := true;
   outputMemo.Text := 'Connection established!';
except
   on E: Exception do
   begin
      // dem Benutzer und dem Programmierer eine aussagekräftige Meldung geben
      // allgemeine Beschreibung zu Beginn der Meldung
      E.Message := 'Fehler beim Öffnen der Datenbank'#13#10+
         E.Message + #13#10 +
         // Details für Programmierer am Ende der Message
         SQLConnection1.ConnectionString;

      // um den Benutzer optimal zu unterstützen kann man den HelpContext setzen
      E.HelpContext := HELPCONTEXT_CONNECTION_FAILED;

      raise;  // Exception neu auslösen, Exceptionklasse bleibt erhalten
   end;
end;

2. Regel:
nicht Exceptions abfangen und irgendwas mit

Delphi-Quellcode:

ShowMessage

anzeigen.
Showessage hat in dem Code nicht verloren.
Stellt dir vor die Exception tritt in einer Schleife mit >100 Durchläufen auf.
Ständig popt die gleiche Meldung auf; man kann das Programm nur noch abschiesen
3. Regel:
Man sollte

Delphi-Quellcode:

raise

wesentlich öfters verwenden als

Delphi-Quellcode:

try...except

.
In dem man eigene Exception-Klassen deklariert und diese dann raised kann man besondern in großen Programmen die Fehlerursache genauer lokalisiert.
4. Regel:
Das Prinzip der Informationanreicherung schachteln

Delphi-Quellcode:

procedure TDataModule.CalcTaxInternal(IdCompany:Integer);
begin
  // jede Menge komplizierter Code zur Steuerberechnung
  ...
end;

procedure TDataModule.CalcTax(IdCompany:Integer);
begin
  try
     CalcTaxInternal(IdCompany);
  except
   on E: Exception do
   begin
      E.Message := 'Fehler bei Steuerberechnung für Firma '+IntToStr(IdCompany)#13#10+
         E.Message:
      E.HelpContext := HELPCONTEXT_TAX_CALC_ERROR;
      raise;  // Exception neu auslösen, Exceptionklasse bleibt erhalten
   end;
end;

Selbst bei einer Zugriffsverletzung innerhalb von CalcTaxInternal() bekommt der Benutzer und der Programmierer so eine gute Info wo das Problem ist.
Die eigentliche Steuerberechnung bleibt völlig frei von störenden

Delphi-Quellcode:

try ... except

.

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