Exception oder Return-Code?

[Marsman]

Hallo Ihr!

Ich habe mal eine grundsätzliche Frage zum Thema Ausnahmen: Wann sollte man aus einer Methode heraus Ausnahmen weiterleiten oder diese besser fangen und einen entsprechenden Returncode zurückgeben? Gibt es da so eine Art goldene Regel? :roll:

Beim Weiterleiten kann die aufrufende Methode selbst entscheiden, was getan wird. Es müssen aber ggf. Verbindungen zu im Aufrufer unbekannten Packages hergestellt werden (z.B. java.sql).

Ein Return-Code hingegen kann den Nachteil haben, dass beim mehrmaligen Aufruf einer Methode nacheinander (z.B. zum Lesen verschiedener Datensätze) mehrere verschachtelte If-Blöcke notwendig werden. Außerdem wird die Möglichkeit, ein anderes Objekt zurückzugeben, blockiert.

Ich bin mir irgendwie noch nicht ganz im Klaren, wann ich welche Technik am besten einsetzen soll. Die dritte Variante, eine eigene Exception zu definieren und zu werfen, wollte ich wegen des Aufwands erstmal außer acht lassen.



Titus

 

[SlaterB]

also grundsätzlich steht die Frage, welche Art von Fehlern du bearbeitest,
was du als Ausnahme ansiehst,
es gibt ja manchmal ganz regulär keine korrekte Lösung,
etwa beim parsen eines unbekannten Strings in eine Zahl,
da halte ich es von Java für übertrieben, ständig teure Exceptions zu schmeißen,
da kann man auch einen bestimmten Rückgabe-Typ wie null als 'geht nicht'-Fall belegen,

-----
in anderen Fällen wie fehlerhafter DB-Connection, da machen die ernsten Exceptions Sinn,
wenn eine Operation diese nicht behandelt, dann sollte man die weiterleiten,

eine UMWANDLUNG in einen bestimmten Rückgabetyp, wozu?
statt die Exception zu fangen muss nun der Aufrufer den Rückgabetyp prüfen,
wo ist der Unterschied?

das kann komfortabel sein, wenn in einem Stück Code viele Exceptionarten auftreten,
und ein Verschachtelung von if/ else die alternativen Behandlungen/ den Programmfluss viel einfacher beschreiben als lauter try/ catches

also durchaus nicht zu verachten, allgemein würde ich das aber als kein sauberes Vorgehen ansehen

 

[SnooP]

Ich versteh's ehrlich gesagt nicht wirklich...

Eine Exception sollte überall geworfen werden... bis letztlich eine Methode auf oberster Ebene den Aufruf anderer Methoden steuert... diese kann dann alle Exceptions gleichzeitig verarbeiten...

 

[Marsman]

in anderen Fällen wie fehlerhafter DB-Connection, da machen die ernsten Exceptions Sinn,
wenn eine Operation diese nicht behandelt, dann sollte man die weiterleiten,

...dabei sehe ich nur eben das Problem, dass sich der Aufrufer mit Teilen des SQL-Package befassen muss. Ich wollte das in meiner Datenbankklasse kappseln.

Wie gesagt, mir sind die Vor- und Nachteile der jeweiligen Variante klar. Es fällt mir nur immer wieder schwer, mich für eine davon zu entscheiden. Aber dein Beitrag hat mir erstmal eine grobe Richtschnur gegeben. :wink:


Titus

 

[hupfdule]

...dabei sehe ich nur eben das Problem, dass sich der Aufrufer mit Teilen des SQL-Package befassen muss. Ich wollte das in meiner Datenbankklasse kappseln.

Du kannst die geworfenen Exceptions auch in eigene Exceptions wrappen. Damit kannst du das etwas detaillierter steuern.

In der Regel wirfst du Exceptions, wenn das Ergebnis ein tatsächlicher Fehler ist, der nicht auftreten sollte. In Rückgabewerten Fehlercodes unterzubringen, solltest du dir auf jeden Fall verkneifen.

 

[SlaterB]

jo, das ist dann die Situation, dass sich die Art des Fehlers verändert,
wenn der Aufrufer von SQL nix wissen darf, dann muss ein anderer Fehlertyp wie 'MyExceptionDBFehler' her,

diese Frage könnte man unabhängig von 'Exception oder Rückgabewert' betrachten,

 

[Marsman]

Du kannst die geworfenen Exceptions auch in eigene Exceptions wrappen. Damit kannst du das etwas detaillierter steuern.

Das wäre eine dritte Variante, die ich auch schon in Erwägung gezogen hatte. Allerdings war mir das zu viel Aufwand. Ich wollte vermeiden, für die eigene Exception eine eigene Klasse zu definieren. Oder darf ich das auch innerhalb meine Datenbankklasse? Also etwa so:

class Database () {
    public void setConnection() {
    try {
    ...
    } catch (SQLException excp) {
        throw new MyDBException();
    } catch (ClassNotFoundException excp) {
        throw new MyDBException();
    }

    class MyDBException extends Exception {
    ...
    }
}

Titus

 

[hupfdule]

Oder darf ich das auch innerhalb meine Datenbankklasse?

Natürlich darfst du das auch dort.

Aber eher so:

    } catch (SQLException excp) {
        throw new MyDBException(excp);
    } catch (ClassNotFoundException excp) {
        throw new MyDBException(excp);
    }

Damit hast du die original Exception noch in deiner Wrapper-Exception drin und kommst auch an diese Info heran, wenn sie nötig ist.

 

[SlaterB]

probiert doch aus? soll dir das der Compiler sagen, nicht das Forum

 

[Marsman]

probiert doch aus? soll dir das der Compiler sagen, nicht das Forum

Ja, mach ich sonst auch. Allerdings wende ich mich an das Forum, um nach einer "vernünftigen" Lösung zu fragen. Nicht alles, was der Compiler erlaubt oder die Doku gestattet, ist auch sauberer Code.


Titus