Designfrage: try-catch-throws

Valgard

Mitglied
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

Bekanntes Mitglied
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

Top Contributor
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

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

Major_Sauce

Bekanntes Mitglied
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

Top Contributor
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

Top Contributor
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.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
L Designfrage: Dispatcher-Programmierung - redundante Auslegung Allgemeine Java-Themen 1
F.S.WhiTeY Designfrage bzw. Meinung zur Umsetzung Allgemeine Java-Themen 39
G Designfrage Vererbung ja oder nein Allgemeine Java-Themen 9
G Designfrage: Exceptions in Konstruktoren Allgemeine Java-Themen 7
E Wie anfangen? Konzept / Designfrage Allgemeine Java-Themen 17
heart_disease Designfrage: Statische Konfigurationsklasse Allgemeine Java-Themen 10
sliwalker Designfrage: Dateninhalte in Komponenten variabel halten Allgemeine Java-Themen 4
N DesignFrage FactoryPattern Allgemeine Java-Themen 7
N verschiedene Klasse laden (Designfrage) Allgemeine Java-Themen 2
A Designfrage zu Dateimanager Allgemeine Java-Themen 4
O Designfrage Allgemeine Java-Themen 6
T Designfrage: Viele, kleine Objekte Allgemeine Java-Themen 13
T Designfrage: Audiochat Allgemeine Java-Themen 3
S Designfrage Allgemeine Java-Themen 3
T Testing JUnit5: try ... catch arbeitet nicht sauber Allgemeine Java-Themen 6
M IndexOutOfBoundsException / Try-Catch Allgemeine Java-Themen 9
K Zweifacher Try-Catch Allgemeine Java-Themen 6
ralfb1105 LogManager logger schreibt nicht in Catch() Zweig Allgemeine Java-Themen 2
C try-catch Block Verständnisfrage Allgemeine Java-Themen 14
F Try/catch über ganze Klasse Allgemeine Java-Themen 9
C Unendlich Wiederholungsfehler bei try catch - Block Allgemeine Java-Themen 3
H try catch Allgemeine Java-Themen 4
E Immer nur der Catch-Zweig Allgemeine Java-Themen 3
N String aus Try/Catch-Block übernehen Allgemeine Java-Themen 14
B Execption auf Oberfläche werfen, try-catch-Block Allgemeine Java-Themen 6
T class.newinstance + try/catch-konstruktor Allgemeine Java-Themen 6
R return in try-catch-Blöcken Allgemeine Java-Themen 6
I Exceptions - weder catch- noch finally-Klausel funktioniert Allgemeine Java-Themen 12
F try und catch Blöcke Allgemeine Java-Themen 3
Final_Striker Exceptionhandling: Richtige Verwendung des Try/Catch Blocks Allgemeine Java-Themen 14
M Try-Catch: wie wird Variable bei Exception initialisiert? Allgemeine Java-Themen 8
P Methodenaufruf von catch Allgemeine Java-Themen 2
S native methoden in try / catch ? Allgemeine Java-Themen 3
V Was tun mit "nötigen" Catch-Blöcken? Allgemeine Java-Themen 3
V Try-Catch und Code der folgt? Allgemeine Java-Themen 3
B Try/Catch in While-Schleife mit Scanner - Hilfe! Allgemeine Java-Themen 3
E try/catch Block um ganzes Programm Allgemeine Java-Themen 10
T rießiger try - catch - Block Allgemeine Java-Themen 13
M try-catch (Wie erzwing ich die catch-Anweisung)? Allgemeine Java-Themen 13
L Try ... Catch Allgemeine Java-Themen 3
C OpenJDK - FileReader throws FileNotFoundException Allgemeine Java-Themen 19
D Throws Exceptions Allgemeine Java-Themen 14
S was bedeutet: throws IOException Allgemeine Java-Themen 1
U throws exception . Allgemeine Java-Themen 2

Ähnliche Java Themen


Oben