Exception werfen nur welche?

[waldemar]

Halllo,

habe hier ein buch vor mir liegen, welches meine Fragen nicht beantworten kann, daher nerve ich euch mal.

try{}
catch(Exception e)
{}

Es gibt ja zig Ausnahmen doch welche Exception soll ich denn angeben? Immer diese wo ich vermute, dass hier ein Fehler auftreten kann? Oder warum kann ich nicht einfach Exception nehmen das geht ja immer?

 

[Noctarius]

Wenn ich deine Frage richtig verstehe, möchtest du wissen, wann du welche Exceptions abfangen sollst, richtig?

Naja das liegt hauptsächlich am Programm. Wenn du eine SQL Verbindung öffnest liegt die Vermutung nahe, dass ein Fehler bei der Verbindung zum SQL Server auftreten kann, eben eine "SQLException".

Wenn du wiederum auf das Dateisystem zugreifst könnte die Datei nicht vorhanden sein "IOException".

Nun kommt es drauf an, ob du nur einen gewissen Fehler abfangen möchtest, z.B. einen der oben genannten, oder generell versuchst alles zu erwischen.

Bei mir kommt es immer auf die Gegenheit an. Bei oben genannten Dingen greife ich auf die spezifische zurück bei grösseren Funktionen wo mehrere Sachen passieren könnten benutze ich die Bases Exception.

Aber im allgemeinen macht es keinen grossen Unterschied da alle spezifischen Exceptions von der Basis Exception abstammen. Sie definieren halt nur eine gewisse Untermenge an Fehlern und lassen Andere, die nicht zu eben dieser Untermenge gehören, durch

 

[waldemar]

Wenn ich deine Frage richtig verstehe, möchtest du wissen, wann du welche Exceptions abfangen sollst, richtig?

nein, das wann ist mir schon klar. Nur warum kann ich nicht die Mutter der Ausnahmen "Exception" jedesmal nehmen (dann muss ich keine 50 andere auswendiglernen oder nachschlagen) wenn ich sowieso eine konkrete Fehlermeldung bekomme egal welche Exception ich nehme?

 

[Wildcard]

nein, das wann ist mir schon klar. Nur warum kann ich nicht die Mutter der Ausnahmen "Exception" jedesmal nehmen (dann muss ich keine 50 andere auswendiglernen oder nachschlagen) wenn ich sowieso eine konkrete Fehlermeldung bekomme egal welche Exception ich nehme?

Für mich ist es ein sehr großer Unterschied ob ich eine NullPointer, eine IllegalArgument, oder eine OutOfBoundsException bekomme...

 

[Noctarius]

Allgemein sollte man versuchen solche Exceptions zu vermeiden

Nee aber ich denke auch, dass es sehr wohl an bestimmten Stellen interessant ist zu wissen welche Exception geworden wurde, und das nicht nur anhand des Fehlertextes.

Aber hatte mein Satz deine Frage nicht klargestellt? "WANN WELCHE abgefangen werden sollte"

Auch wenn mich jetzt viele hauen werden, du musst nicht alle auswendig lernen (in Javadocs steht meistens drin welche geworfen werden können) und Eclipse und andere IDEs geben dir auch an welche fehlt

 

[waldemar]

Nee aber ich denke auch, dass es sehr wohl an bestimmten Stell
en interessant ist zu wissen welche Exception geworden wurde, und das nicht nur anhand des Fehlertextes.

das heißt also:

1. Ich fange immer eine Ausnahme ab vor der ich denke das genau diese Auftritt. Sprich wenn der Benutzer z.B. durch 55/ 0 teilt fange ich nicht eine Exception e ab sondern eine DivisionByZero e oder so ähnlich richtig?

 

[Noctarius]

Jo genauso könnte man es sehen. Wie gesagt wenn du zu einem SQL Server connecten willst, könnte der Server nicht erreichbar sein, die Datenbank nicht existieren, ebenso die Tabelle oder Spalte oder deine Rechte reichen nicht aus, usw usw usw... Das wären alles SQLExceptions.

 

[waldemar]

Jo genauso könnte man es sehen. Wie gesagt wenn du zu einem SQL Server connecten willst, könnte der Server nicht erreichbar sein, die Datenbank nicht existieren, ebenso die Tabelle oder Spalte oder deine Rechte reichen nicht aus, usw usw usw... Das wären alles SQLExceptions.

aber was würde passieren, wenn der SQLserver down ist und ich nicht die SQLException benutze sondern die Exception ?

Würde ich dann keine Fehlermeldung ala:"SQL server ist busy oder steht nicht zur Verfügung" bekommen?

 

[Noctarius]

Doch sicher würdest du die bekommen, da SQLException von Exception abgeleitet ist. Aber es ist in bestimtmen fällen so, dass man eine gewisse Exception haben möchte aber eine Andere nicht.

Allgemein sollte man versuchen Fehler möglichst spezifisch abzufangen (sonst hätte die Aufsplittung ja wohl kaum Sinn).

 

[waldemar]

catch (SQLException e)
{  
System.out.println(e);
}

was wäre wenn ich obige variable e nicht ausgebe sondern einfach ein JOptionPane mache mit dem Text:

JOptionPane.showMessageDialog(null, "SQL Server antwortet nicht","Sever down",JOptionPane.ERROR_MESSAGE);

dies versuchte ich schon mal und es klappte nicht nur wenn ich die variable e noch an obigen String

"SQL Server antwortet nicht" + e ranhänge hat es funktioniert ??

 

[waldemar]

Doch sicher würdest du die bekommen, da SQLException von Exception abgeleitet ist.

aber das sagt doch schon alles und du sagst es selbst. Warum sollte ich dann andere Exceptions außer die Exception Mutter aller Ausnahmen benutzen, wenn ich sowieso eine konkrete Ausgabe bekomme? Das erklär mir jetzt mal, danke!

 

[Wildcard]

Weil verschiedene Operationen auch mehrere Exceptions werfen können und du ExceptionA anders behandeln willst als ExceptionB.
Ausserdem werden zum Teil auch eigene Exceptions definiert, denen eigene Parameter mitgegeben werden.

 

[Jango]

Wenn du beispielsweise mit Dateien arbeitest, weißt du gar nicht, welcher Fehler gerade auftritt, wenn du nur die "globale" Exception abfängst. Ist die Datei nicht da - ist der Pfad falsch, u.s.w.. Die Fehlersuche wird zum Abenteuer.
Wenn es keinen Sinn hätte, verschiedene Exceptions abzufangen, hätten die Macher von Java sich bestimmt nicht die Mühe gemacht. :wink:

 

[waldemar]

Weil verschiedene Operationen auch mehrere Exceptions werfen können

Das ist z.B. ein Grund den ich verstehe, denn bei der super Exception hätte ich ja keine differenzierte Ausgabe.

das gleiche natürlich auch bei Jango.

Also bin ich der Meinung kann man von Fall zu Fall abwägen ob man die super Exception angibt oder eine der abgeleiteten Klassen, wie seht Ihr das?

 

[Hilefoks]

Wenn du immer ganz allgemein Exception fängst, fängst du damit auch alle Programmierfehler. Meiner Meinung nach sollte man niemals eine normale Exception fangen und auch nie selbst eine auslösen - sondern immer eine abgeleitete.

void foo(Object o) {
    try {
        doSomething(o.toString());
    } catch(Exception e) {
        //....
    }
}

Kein tolles Beispiel, aber egal. Hier wird z.B. auch der Programmierfehler (o könnte null sein) verluckt und natürlich auch jeder andere Programmierfehler in doSomething()...

Wie gesagt: Für mich sind normale Exceptions (und ein paar andere wie NullPointerException) immer Programmierfehler und werden von mir nie gefangen. Sollte eine solche Exception auftreten habe ich einen Fehler gemacht. Im Fall einer NullPointerException habe ich z.B. versäumt diesen Fall zu testen.

MfG,
Hilefoks

 

[waldemar]

Wenn du immer ganz allgemein Exception fängst, fängst du damit auch alle Programmierfehler. Meiner Meinung nach sollte man niemals eine normale Exception fangen und auch nie selbst eine auslösen - sondern immer eine abgeleitete.

void foo(Object o) {
    try {
        doSomething(o.toString());
    } catch(Exception e) {
        //....
    }
}

Kein tolles Beispiel, aber egal. Hier wird z.B. auch der Programmierfehler (o könnte null sein) verluckt und natürlich auch jeder andere Programmierfehler in doSomething()...

Wie gesagt: Für mich sind normale Exceptions (und ein paar andere wie NullPointerException) immer Programmierfehler und werden von mir nie gefangen. Sollte eine solche Exception auftreten habe ich einen Fehler gemacht. Im Fall einer NullPointerException habe ich z.B. versäumt diesen Fall zu testen.

MfG,
Hilefoks

da haste recht , das beispiel ist so abwegig bzw. realitätsfern das ich Probleme mit dem Verstehen habe :lol: wieso könnte "o" auch "0" sein? 0.troString() ist doch quark...

Hat jemand ein realistisches Beispiel so mitten aus dem Leben :wink:

 

[Noctarius]

Für mich ist es ein sehr großer Unterschied ob ich eine NullPointer, eine IllegalArgument, oder eine OutOfBoundsException bekomme...

Allgemein sollte man versuchen solche Exceptions zu vermeiden

Seh ich genauso, sowas sollte man nicht per Try/Catch abfangen sondern vorher schon wissen ob es sein könnte und evtl darauf testen bevor man etwas tut.

@ Waldemar: Null ist nicht der Zahlenwert 0, sondern ein Nullobjekt. Jedes nicht klar initialisierte Objekt ist erstmal ein Nullobjekt. Das heisst einfach soviel wie "mir wurde noch keine Referenz zugewiesen".

Damit ist objekt.Test() nicht möglich wenn objekt==null ist, weil es auf kein verwendbares Objekt verweisst.

 

[NTB]

Du lässt den Benutzer eine Datei angeben und versuchst diese mit Java zu öffnen. Wenn Du nur "Exception" abfängst, kann Dein Programm nicht unterscheiden, ob die Datei nicht vorhanden war, also der Dateiname falsch (FileNotFoundExcepion), oder ob es Schwierigkeiten gab, die Datei zu lesen (IOException). Das sind grundlegend verschiedene Probleme, auf die Dein Programm auch verschieden reagieren sollte.