Designfrage: try-catch-throws

[Valgard]

Hallo,
ich habe mal eine allgemeine Frage, in welcher es um try-catch-Statements geht. Wie man diese einsetzt und programmiert ist mir klar. Aber nehmen wir an, man hat ein komplexeres Programm mit umgesetzter 3-Schichten-Architektur, wo Daten, Logik und Gui voneinander getrennt sind. In den Datenklassen hole ich mir dann Daten aus einer Datenbank, die Daten werden in den Logik-Klassen angepasst/aggregiert/was auch immer und dann in der Gui dargestellt. Hierbei muss ich zwangsläufig einen try-catch-Block in meine Datenklasse packen, wo ich die Daten aus der Datenbank hole (SQLException). Oder ich füge hier ein "throws" ein und lasse dann eine der anderen Schichten das try-catch ausführen.
Meine Frage hierbei ist: Gibt es irgendeine allgemeine Konvention oder den "besten" Weg, wo man das try-catch ausführt oder ist das relativ egal? Ich würde ja sagen, man muss das auf der Logikebene machen, aber am einfachsten wäre es auf der Gui-Ebene, wo man in einem catch dann direkt ein JOptionPane mit der Fehlermeldung anzeigen könnte.

 

[Major_Sauce]

Nabend,

also wenn dus dir einfach machen willst, nimm try/catch.
Throws bedeutet natürlich immer dass du das ganze irgend wo anders mit nem try/catch abfangen musst und das ist nicht immer gut.
Natürlich gibt es Situationen bei denen sich ein Throws anbiete, wenn zu zum Bleistift eigene Fehlermeldungen in die Überklasse transportieren willst, aber diese sind meißt die Ausnahme.

mfg Major

 

[Saheeda]

Ich sehe das anders. Wenn der User Daten anfordert, muss er informiert werden, wenn und warum es nicht klappt. Nicht immer ist ein Boolean, eine leere Collection o.ä. die beste Lösung. Manche Fehler (wie IllegalArgument, Nullpointer, OutOfBounds o.ä.) sollten sogar fliegen. Die überall abzufangen kanns Debuggen unglaublich schwer machen. Im Zweifelsfall passiert einfach nix und weder User noch Entwickler weiß so genau, warum.

 

[Tobse]

Ich stimme Saheeda zu. Normalerweise behandelt man solche Exceptions als RuntimeExceptions. Die werden dann auf sehr Hoher Ebene gefangen (z.B. die Klassen, die deine GUI organisieren) und lösen dort Fehlerdialoge aus.

Manche Applikationen zeigen dir ein Fenster álá "Das Programm hat einen Fehler festgestellt und wurde beendet. Fehlerbericht senden?". Das passiert immer genau dann, wenn eine Exception bis ganz nach oben Durch gekommen ist.
Exceptions, die du nicht behandeln kannst, solltest du auch immer weiterreichen.

 

[Valgard]

Ah ok, vielen Dank für die hilfreichen Antworten

 

[Major_Sauce]

Sehe ich nicht unbedingt anders, aber es kommt meiner Meinung nach auch auf die Menge der Exceptions drauf an.
Es gibt Menschen, leider, die meinen dass sie ein ganzes Spiel in 3 Klassen schreiben müssten.
Nun sagen wir mal es gibt eine main-Class und nur weil der jetzt die Game-class aufrufen möchte muss der erstmal 40 Exceptions handeln ?
Das ganze wird dann zu unüberichtlich da man dann im höheren Level keine Ahnung mehr hat wieso die Exception denn überhaupt geworfen wurde.
Da macht es dann wohl auch sinn einfach direkt ein try/catch zu nehmen und die Exception direkt in die Console schreiben oder ähnliches.
Damit will ich nicht sagen dass ich Saheeda unrecht gebe, ganz im Gegenteil, aber ich finde solche Fragen sind immer zu situationsbeding.

mfg Major

 

[Thallius]

Das beste ist es immer noch so zu programmieren, dass man gar keine Exceptions bekommt.

 

[Tobse]

Das beste ist es immer noch so zu programmieren, dass man gar keine Exceptions bekommt.

Bitte was? Ist das dein Ernst? Diese Aussage kann ich zu 0% nachvollziehen.

 

[Valgard]

Joa, aber wenn man wie in meinem Fall mit einer Datenbank arbeitet, kann man diese Thema nicht umgehen^^

 

[Thallius]

Bitte was? Ist das dein Ernst? Diese Aussage kann ich zu 0% nachvollziehen.

Tja wenn ich sowas lese, dann frage ich mich wie ich es nur 20 Jahre geschafft habe in C ohne Exceptions auszukommen. Da gab es nämlich keine....

Ich kann jede Exception verhindern indem ich vorher Abfrage ob die Aktion die ich machen will auch vallide ist. Also bevor ich ein File öffne, schaue ich erstmal nach ob das überhaupt da ist etc...

Warum ich bei Datenbankbenutzung nicht ohne Exceptions auskommen soll finde ich noch spannender. Ich habe gerade in Objective-C eine große DB Anwendung geschrieben und dort gibt es auch keine Exceptions, zumindest nicht solche wie sie in Java zu tausenden angewendet werden, sondern nur wirklich richtige Exceptions die man eben nicht software seitig abfangen kann.

Gruß

Claus

 

[Tobse]

Tja wenn ich sowas lese, dann frage ich mich wie ich es nur 20 Jahre geschafft habe in C ohne Exceptions auszukommen. Da gab es nämlich keine....

Not macht erfinderisch. Natürlich bist du ohne ausgekommen - wie denn auch, wenn es keine gibt. Das macht Exceptions aber nicht per-se Schlecht.

Ich kann jede Exception verhindern indem ich vorher Abfrage ob die Aktion die ich machen will auch vallide ist. Also bevor ich ein File öffne, schaue ich erstmal nach ob das überhaupt da ist etc...

Richtig. Wenn deine Software an 200 Stellen Dateien öffnet, hast du 200 mal den selben Code ge Copy-&-Pasted, der
alle Fehlerfälle behandelt (Datei nicht gefunden, Verzeichnis nicht gefunden, Keine Leserechte auf der Datei, Datei wird gerade geschrieben, ...)
Wenn sich jetzt an der Fehlerbehandlung etwas ändert, musst du 200 stellen Code anfassen. Jippie.
Eine Exception fliegt einfach nach oben weiter und du musst dich nur an einer Stelle um die Behandlung kümmern (z.B. eine Fehlermeldung álá "Die Daten konnten nicht geladen werden, weil eine erforderliche Datei nicht gefunden wurde.")

In Objective-C [...] gibt es auch keine Exceptions, zumindest nicht solche wie sie in Java zu tausenden angewendet werden.

Du enkräftest doch dein eigenes Argument: In Java sind Exceptions die Methode, um Fehler zu behandeln. Warum also in einem Java-Forum etwas anderes verbreiten? Error-Codes sind nämlich keinen deut besser.

 

[Saheeda]

@Tobse
Verifizieren kann man aber auch in eigene Methoden auslagern und muss dann nur jedes Mal Check.verify(file) aufrufen. Ganz ohne Copy'n'Paste.