Fehlerbehandlung

[MatheStein]

Hey Leute,

hab vllt eine etwas dumme Frage.

Normalerweise fange ich in Java sämtliche Fehler per if-Konstrukte etc ab.
Wann sollte man von diesem Vorgehen abweichen und eigene Exception für Fehlerfälle implementieren um diese dann im Fehlerfall auszulösen?

Gibts da gewisse Konventionen an die man sich richten kann?

Gruß

 

[SlaterB]

Programmieren besteht nicht aus Konventionen, in erster Linie programmiert man so, wie es am besten passt,

Exceptions machen Sinn, wenn viele verschiedene Schichten durchlaufen werden,
wenn 10 verschachtelte intere Methodenaufrufe eine Gesamtaktion 'lade Daten aus Datei' bei einem Fehler sowieo insgesamt abgebrochen werden müssen,
ohne Exception müstte man da an zig Stellen if einbauen, das macht man vielleicht einmal, dann hat man es gelernt, spätestens wenn man es woanders schöner sieht

 

[MatheStein]

vielen dank für die antwort

kann das leider nur nicht ganz nachvollziehen.

Hast du vllt ein paar zeilen code an dem man sich das Ganze verdeutlich kann?

gruß und schönen sonntag noch

 

[Landei]

Die Frage ist, ob es sinnvoll ist, den Fehler lokal zu behandeln. Wenn ja, ist es so OK, wie du es machst. Wenn nicht, würde es so zu kompliziert, und deshalb gibt es Exceptions: Angenommen deine Anwendung liest an verschiedenen Stellen XML-Dateien ein. Jetzt können zum einen Datei-Fehler, zum anderen Parser-Fehler auftreteten. Viel machen kannst du in solchen Fällen nicht, du kannst nur die Fehler wegloggen und den Nutzer informieren. Da bietet es sich an, das Ganze zentral zu regeln, indem du die Exception relativ weit oben in der Aufrufhierarchie (oder sogar in einem UncoughtExceptionHandler) auffängst, und dich an den einzelnen Stellen, wo du XML liest, nicht weiter darum kümmerst.

 

[Der Müde Joe]

Mit Slaters Beispiel des File-Ladens:

Was kann schiefgehen, wenn man das Dateiauswahldingens öffnet?
1. Dateien korrupt
2. Festplatte nicht vorhanden
3. irgend ein übertragungsfehler
4. keine Zugriffs berechtigung
......

Nun, eine Schicht baut auf die andere auf.

ist die Festplatte da...weiter
hat man Zugriff... weiter...
ist die datei ok...weiter...
wurde die Datei sauber geladen... perfekt...

Ein Ausfall in einer dieser Teile bringt das ganze System ins wanken. Keine Festplatte, keine Datei. kein Zugriff keine Datei...
Jetzt könnte man das ganze mit ifs lösen.
if(hd da) return ok else bad ..weiter
if( had da && zugriff ok ) ... weiter
if( zugriff && CRC ok ) ...

Andereseits könnte man einfach eine Exception schreiben. Wenn schief geht gehts sowieso schief.
Die Exception wird an der Stelle gefangen (try{}catch()}), wo man sie sinnvoll behandeln kann.
Zb beim FileDialog...Sorry, keinen Zugriff....Sorry, PC kaputt.

Somit hat man sich ein paar if else gesparrt UND man kann den Fehler dort behandeln, wo man
es benötigt (die Exception wird solange nach oben gereicht, bis sie jemand fängt)

 

[MatheStein]

ah danke jungs

also besonders interessant werden die Exception bei der Implementierung von Komponenten, wo der Nutzer der Komponente nach einem Fehlverhalten in der Komponente selbst über den weiteren Verlauf des Programms entscheiden soll und nicht der Programmierer der Komponente selbst oder?

Gruß

 

[SlaterB]

selbst ein und derselbe Programmierer schreibt mehrere Programmteile, von denen manche allgemein sind und an verschiedenen Stellen genutzt werden,
der Gegensatz (Teil-)Programm <-> Anwender/ Aufrufer kann also auch innerhalb eines Programmes nur von einem Programmierer auftreten,

und mit Rückgabewert kann man genauso den Aufrufer entscheiden lassen, ein if pro Aufrufer ist nicht komplizierter, als wenn jeder von diesen try/ catch schreiben muss,
es ist nur die Frage, wie aufwendig dies im (Teil-)Programm einzubauen ist, und inwiefern das nachvollziehbar ist, besonders bei verschiedenen möglichen Fehlern,
wenn man es mit Werten und if/ else hinbekommt, kann man ruhig dabei bleiben