PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Java: genauere Fehlermeldungen


ooAlbert
2007-02-02, 10:42:59
Hallo,

ich versuch gerade mein Java programm fehlerfrei zu bekommen, dh. etwaige störungen von außen zu beseitigen.
Mein problem ist jetzt, das ich zwar fehler erstellen kann und das programm auch abbricht aber ich nicht wirklich gezeigt bekonmme wo das abgebrochen ist.

Gibt es demzufolge eine möglichkeit diese fehlermeldungen zu erweitern oder anderweitig mehr informationen rauszupressen?

mfg

redfalcon
2007-02-02, 10:46:34
Womit fängst du die Fehler denn ab? Try+Catch?

ooAlbert
2007-02-02, 11:17:32
unter anderem ja, es treten sicher auch fehler auf die erst außerhalb dieser bläcke existent sind.

Shink
2007-02-02, 11:19:45
try {
String a=null;
a.trim();
} catch (Exception ex) {
ex.printStackTrace();
}

PatkIllA
2007-02-02, 11:24:18
unter anderem ja, es treten sicher auch fehler auf die erst außerhalb dieser bläcke existent sind.
Sowas rattert dann doch inklusive Stacktrace und Zeilennummer auf der Konsole durch.
Von einem allgemenen Abfangen würde ich in den meisten Fällen Abstand nehmen.

Abnaxos
2007-02-02, 13:20:34
Du willst ein Log schreiben. ;) Ich sage immer: Gutes Logging ersetzt den Debugger, weil man dann einfach nachlesen kann, wann das Programm was gemacht hat und wo welche Fehler aufgetreten sind.

log4j (http://logging.apache.org/log4j/docs/index.html) ist ein sehr gutes Logging-Paket (wenn dort leider auch die Unterscheidung der Logging-Levels "debug" und "trace" fehlt), wobei ich das nochmal mit commons-logging (http://jakarta.apache.org/commons/logging/) kapseln würde, um sich nicht auf eine spezifische Logging-Lösung zu beschränken. java.util.logging existiert natürlich auch (seit 1.4), aber irgendwie konnte ich mich damit nie so recht anfreunden.

Shink
2007-02-02, 13:39:38
wobei ich das nochmal mit commons-logging (http://jakarta.apache.org/commons/logging/) kapseln würde, um sich nicht auf eine spezifische Logging-Lösung zu beschränken. java.util.logging existiert natürlich auch (seit 1.4), aber irgendwie konnte ich mich damit nie so recht anfreunden.
Ich irgendwie auch nicht. Allerdings gibt es bei commons-logging anscheinend irgendwelche Probleme (z.B. mit Tomcat), sodass davon inzwischen eher abzuraten ist.

Wichtig auch bei Logging ist, dass man alles irgendwie irgendwo "catcht" (zumindest ganz aussen - zur Not kann man ja die Exception nach dem Loggen weiter"werfen")

Thorn of Roses
2007-02-02, 18:17:08
Hallo,

ich versuch gerade mein Java programm fehlerfrei zu bekommen, dh. etwaige störungen von außen zu beseitigen.
Mein problem ist jetzt, das ich zwar fehler erstellen kann und das programm auch abbricht aber ich nicht wirklich gezeigt bekonmme wo das abgebrochen ist.

Gibt es demzufolge eine möglichkeit diese fehlermeldungen zu erweitern oder anderweitig mehr informationen rauszupressen?

mfg

Inwiefern erweitern. Standardmäßig haben die ja einen Konstruktor mit Exception("String"). Sprich du kannst die auch dementsprechend formulieren.

Mehr als die Zeile ist glaub ich nicht rauszuhohlen bzgl. WO.

Aber ich bin auch noch nicht so sehr weit fortgeschritten. Kann auch sein das ich dich falsch verstehe.

mit codenden Grüssen,

-Thorn-

Monger
2007-02-02, 18:24:22
Bei Exceptions ist vorallem wichtig, dass man sie wirklich nur dann fängt, wenn man was dagegen tun kann, bzw. weiß was genau denn eigentlich schief läuft. Lieber die Exception ne Ebene hochwerfen, oder fangen und neue, präzisere Exceptions erzeugen, als auf unterster Ebene fangen und dort mit "Es ist ein Fehler aufgetreten! Fehler Nr. 37920740" quittieren.

Abnaxos
2007-02-02, 23:03:42
Lieber die Exception ne Ebene hochwerfen, oder fangen und neue, präzisere Exceptions erzeugen, als auf unterster Ebene fangen und dort mit "Es ist ein Fehler aufgetreten! Fehler Nr. 37920740" quittieren.
Wegen fehlender Abstraktion und auch wegen der "Deklarations-Hölle" (ich mag einfach nicht durch 10 Klassen hindurch ständig 5 oder mehr Exceptions deklarieren, auf RuntimeExceptions zu setzen finde ich auch äusserst unelegant) würde ich eher fangen und eine neue Exception werfen, die ursprüngliche Exception aber natürlich unbedingt dazu packen.

Wenn ich in irgend einem Interface z.B. eine SQLException deklariere, lege ich damit eigentlich bereits fest, dass die Implementation irgendwas mit JDBC macht. Wenn ich jetzt aber eine andere Implementation dazu bauen will, die eine OO-DB oder eine Textdatei verwendet, kann ich mit dieser deklarierten SQLException nichts anfangen. Daher deklariere ich lieber eine StorageException oder so.

Ausserdem lesen sich solche Stack-Traces IMHO schön: "Es ist etwas schief gegangen" -- "es ist etwas schief gegangen, beim Verarbeiten der Anweisung in Datei x, Zeile y" -- "Ich konnte das Objekt der Klasse XY nicht erzeugen" -- "Der Konstruktor hat eine Exception geworfen" -- "Der Konstruktur meinte: IllegalArgumentException ...". Das ist schön von oben nach unten immer etwas detaillierter und zeigt einem genau den Weg, den der Fehler genommen hat bzw. in welchem Kontext er aufgetreten ist.