Methoden Überflüssige Exceptions

[HimBromBeere]

Malzzeit,

habe mal wieder ein Gewissensproblem. Ich habe eine Funktion Session#isStarted(), die angibt, ob eine Session (was auch immer...) gestartet wurde. Die Klasse Session stellt jedoch noch eine Reihe Funktionen zur Verfügung, die jedoch nur dann laufen, wenn diese Session bereits getartet wurde. Dsher prüfe ich vor jedem Aufruf einer solchen mit Session#isStarted(), ob dem so ist. Jetzt schmeißt aber jede dieser Funktionen auch noch eine SessionRunningException für den Fall, dass die Session eben nicht läuft (jetzt da ich das schreibe, klingt das ziemlich verwirrend). Kann ja sein, dass mal jemand den Aufruf von isStarted() vergessen hat und deshalb die Funktion u.U. nicht funktioniert.
JEtzt prüf´ ich also mehr oder weniger zweimal das Selbe (einmal explizit mit isStarted() und einen implizit über die Exception). Nur irgendwie hab ich keine Lust, jedes Mal die Exception mitzuschleppen, obwohl ich den Zustand ja bereits explizit geprüft hab.

Sofern das irgendjemand verstanden hat, wäre ich dankbar, wenn mir jemand einen Rat geben könnte, wie ich die innere Stimme, die mir sagt, Exceptions sind nicht zur Programmsteuerung da, ignorieren kann.

 

[faetzminator]

Wenn [c]SessionRunningException[/c] keine [c]RuntimeException[/c] ist, dann musst du (leider) immer einen try-catch-Block erstellen. Da kommst du nicht drum herum. Keine Angst, du bist nicht der einzige, welcher sich über Checked Exceptions nervt...

 

[SlaterB]

Unchecked

(gemeint: Unchecked als Lösung)

 

[Gast2]

Die SessionRunningException stammt von dir? Dann mach daraus ne RuntimeException. Wenn se nicht von dir ist, dann wrap die mit ner RuntimeException.

 

[tfa]

Die SessionRunningException stammt von dir? Dann mach daraus ne RuntimeException.

In dem Fall würde ich java.lang.IllegalStateException verwenden. Die gibt's schon und ist glücklicherweise eine RuntimeException.

 

[HimBromBeere]

Die Idee ist ja schonmal nicht schlecht. Wenn ich jetzt aber meine ganzen Exceptions von RTE ableiten lassen würde, wäre das wahrscheinlich auch nicht das was man vorausschauendes Programmieren nennt. Also wie unterscheide ich, wann ich eine Exception werfen sollte und wann eine (nicht zwangsläufig zu fangende) RTE?

 

[SlaterB]

da gibts ganze Bücher oder als Radikallösung immer bzw. wenigstens als Standard RTE
Checked nur dann wenn du gute Gründe dafür hast, lokaler Einsatz, try/catch angebracht

 

[Sym]

Am besten immer eine Runtime-Exception und diese schön dokumentieren.

Auch Runtime-Exceptions sollten behandelt werden. Du hast dadurch nur keinen Overhead mehr, wenn die Exception durch mehrere Schichten rauscht.

 

[xehpuk]

Also wie unterscheide ich, wann ich eine Exception werfen sollte und wann eine (nicht zwangsläufig zu fangende) RTE?

Siehe dazu im offiziellen Tutorial: Unchecked Exceptions — The Controversy (The Java™ Tutorials > Essential Classes > Exceptions)

In deinem Fall sollte es also ganz klar eine RuntimeException (wie schon speziell genannt: IllegalStateException) sein. Der Client hat die Möglichkeit, den Status über eine Methode abzufragen. Wenn er also eine Methode aufruft, die den gestarteten Status erfordert, ist er sich auch sicher, dass dieser erfüllt ist. Wenn nun (wider Erwarten) eine Exception geworfen wird, hat er einen Fehler gemacht.

@Sym: Wer hat dir denn sowas eingetrichtert? :bae:

 

[HimBromBeere]

Hmmm... so richtig gecheckt hab ich den Unterschied zwischen beiden nicht. Zumindest weiß ich schonmal, dass unchecked Exceptions unchecked Exceptions heißen, weil nirgends geprüft wird, ob sie auch gefangen werden.
Da ich vorher bereits das Vorhandensein einer Session prüfe, sollte diese Exception demnach nur geworfen werden, wenn ein gravierender (Programm-)Fehler vorliegt, der nicht vorherzusehen ist. Hat dafür jemand eine griffigere Formulierung? Ich kann damit zwar was anfangen, aber so richtig greifbar ist das nicht...

 

[...ButAlive]

Im Prinzip hast du recht, denn der Aufrufer könnte ja im catch-Block einfach die Session starten und es dann nochmal probieren. Das könnte er aber auch bei einer Unchecked Exception machen, der Unterschied ist eigentlich nur, dass du die Entscheidung ob ein catch-Block vorhanden sein soll, dem Aufrufer überlässt.

Eigentlich ist die Regel, wenn der Aufrufer in irgendeiner Weiße sinnvoll reagieren kann, nimmt man Checked-Exceptions, falls nicht Unchecked.

Da es aber schwer ist, zu entscheiden ob der Aufrufer noch etwas machen kann oder nicht, überlasse ich meistens die Entscheidung ob catch-Block oder nicht dem Aufrufer.

Viele Sprachen verzichten mittlerweile auf eine Unterscheidung, zum Beispiel Scala oder C#.

Aber mal eine andere Frage, macht es denn Sinn, eine nicht gestartete Session zu haben? Wenn nicht, könntest du doch einfach die Session im Konstruktor starten und würdest dem Problem aus dem Weg gehen.

 

[HimBromBeere]

Macht es denn Sinn, eine nicht gestartete Session zu haben?

Jo, macht es, da man z.B. nur bei inaktiver Session den Zielpfad der Zeichenoperation, die mit der Session verbunden ist, verändern kann (wäre ja doof, wenn man das WÄHREND des Zeichnens könnte). Und einfach eine neue Instanz einer Session zu definieren, finde ich irgendwie auch nich so dolle, da müsste ich schließlich trotzdem die alte erstmal zerstören... ob ich aus der Klasse mal ein Singleton mache:bahnhof:? Werd ich mal bei Gelegenheit drüber philosophieren

 

[Aldimann]

Hi zusammen,

also ich unterscheide ob eine Checked oder Unchecked Exception verwendet wird immer daran ob es Sinn macht im Fehlerfall weiter zu arbeiten.

Beispiel:

IOException wird oft beim Einlesen von Dateien verwendet, wird sie geworfen kann es sein, dass die Datei nicht mehr vorhanden ist, man keine Rechte besitzt oder sonst irgendwas schief gelaufen ist. Das ist aber noch lange kein Grund für Java zu sagen das es an der Stelle die Arbeit einstellt und alles hin schmeißt . Der Programmierer kann also die Exception abfangen und einen "Notfallplan" laufen lassen.

Gegenbeispiel:

IllegalArgumentException wird oft für flasche Methodenparameter geworfen. Gibt also z.B. der User einer API einen falschen Parameter rein, z.B. eine ungültige Id, so kann der Programmierer der API unmöglich sagen wie es im Programmablauf weiter gehen soll. Wie auch er weiß ja noch nicht mal welches Objekt er aus der Datenbank holen soll...

 

[tfa]

Der Programmierer kann also die Exception abfangen und einen "Notfallplan" laufen lassen.

Das kann er auch, wenn IOEx eine RuntimeException wäre. Darüber hinaus gibt es 1000 Fälle, in denen man IOExceptions nicht sofort beheben kann. Warum sollte man also jeden und immer dazu zwingen?

 

[Aldimann]

Naja im prinzip kannst du die gleiche Argumentation auch bei Generics anwenden, denn die kosten auch mehr Code und unterm Strich ist die Funktionalität die gleiche .

Aber wir kommen vom Thema ab... Im Prinzip gibt es keine Totschlagsargumente für oder gegen Checked Exceptions und jeder muss selber wissen was er her nimmt. Um z.B. konkret auf deine Frage einzugehen wären zwei Vorteile von Checked Exceptions, dass sie in jedem fall nur geworden werden können wenn sie auch deklariert wurden und das es durch Compilererrors nicht dazu kommen kann, dass man das Exceptionhandling vergisst.

 

[bygones]

Naja im prinzip kannst du die gleiche Argumentation auch bei Generics anwenden, denn die kosten auch mehr Code und unterm Strich ist die Funktionalität die gleiche .

du hast die Argumentation nicht verstanden - es geht nicht darum, dass man bei unchecked exc. ein paar Zeilen code spart. Es geht darum den Verwender zu zwingen damit umzugehen.

 

[SlaterB]

[..]wären zwei Vorteile von Checked Exceptions, dass sie in jedem fall nur geworden werden können wenn sie auch deklariert wurden und das es durch Compilererrors nicht dazu kommen kann, dass man das Exceptionhandling vergisst.

strenggenommen umgehbar :

public class Test
{
    public static void main(String[] args)
    {
        throwUnchecked(new IOException());
    }

    public static void throwUnchecked(Throwable e)
    {
        Test.<RuntimeException>throwAny(e);
    }

    @SuppressWarnings("unchecked")
    private static <E extends Throwable>void throwAny(Throwable e) throws E {
        throw (E)e;
    }
}

http://www.java-forum.org/codeschni...-throw-undeclared-checked-exception-java.html

 

[faetzminator]

Das "Problem" ist, dass man vielerorts sagen kann: ich weiss, dass hier keine Exception auftreten kann. Dies kann durch einen Check wie [c]isStarted()[/c], eine Validierung o.ä. sein. Und in all diesen Fällen ist eine Checked Exception einfach nur mühsam, welche ich meistens mit Wrappern verberge. Da die IOException bereits als Beispiel gennant wurde: da machts IMHO wirklich bei einigen Methoden Sinn, eine Checked Exception zu werfen. Aber meine Meinung ist, dass Checked Exceptions in Java ein Sprachdesignfehler sind.

 

[Aldimann]

du hast die Argumentation nicht verstanden - es geht nicht darum, dass man bei unchecked exc. ein paar Zeilen code spart. Es geht darum den Verwender zu zwingen damit umzugehen.

Oh Sorry, stimmt! Meiner Meinung nach macht es an bestimmten Stellen Sinn den Aufrufer zu zwingen, dass er ein Exceptionhandling ausprogrammiert. Wie faetzminator allerdings schon geschrieben hat, kann das auch dazu führen, dass es einfach nur nervig wird.

Daher sollte man sich genau Überlegen an welchen Stellen es Sinn wirklich Sinn macht einen Aufrufer zu zwingen ein Exceptionhandling auszuprogrammieren und an welchen eben nicht.

Bin mit der ganzen Diskussion ehrlich gesagt etwas hin und her gerissen...

 

[tfa]

Daher sollte man sich genau Überlegen an welchen Stellen es Sinn wirklich Sinn macht einen Aufrufer zu zwingen ein Exceptionhandling auszuprogrammieren und an welchen eben nicht.

Möglicherweise stimmt das, wenn man es selbst entscheiden kann, also eine selbstdefinierte checked Exceptions verwendet.
In Bibliotheken oder der Standard-API haben checked Exceptions aber nichts verloren, da deren Designer unmöglich die konkreten Anwendungsfälle ihrer API kennen können. Der Nutzen ist also so bescheiden und die Nachteile so groß, dass man wirklich von einem Sprachdesignfehler sprechen muss, den es meines Wissens nur in Java gibt.

 

[HimBromBeere]

Hihi, ich wusste doch, dass diese Diskussion interessant wird...

[OT]Programmieren ist doch häufiger als gedacht Philosophie[/OT]