ALLE exceptions in Log fenster anzeigen

[dermoritz]

Ich hab das schon of bei anderen Programmen gesehen und selbst nur bei QT(C++) gemacht:

Ich würde gerne alle "Throwables" die beim Programmablauf geworfen werden fangen und deren Nachricht in ein Logfenster schreiben. Natürlich ist die Hoffnung das es keine gibt, aber ohne so ein Mechanismus sind die Exceptions bei einer Swinganwendung ja unsichtbar und das ist Mist.

Meine erste Frage wäre: wo baue ich den allesumfassenden try-catch-böock hin? Ein Gui aufruf in der Main sieht ja of so aus(so generiert es Matiss - netbeans' gui builder):
[Java]
public static void main(String[] args) {
try {
UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
} catch ...

...
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
meineGui gui = new meine14Gui();
gui.setVisible(true);
}
});
}
[/code]
Wo soll der alles fangende try-catch-block nun hin. Alles umfassen? InvokeLater umfassen? oder den run-Block oder nur "...new meineGui"?
Die 2. Frage ist, wie das ganze praktisch in Java funktioniert, mit welcher Klasse ("Logger", "Log4j"?) Und wo und wie wird das dann eingebaut?

Danke im Voraus

 

[slawaweis]

mit try catch wird es nicht gehen. Seit Java 5 gibt es diese netten Funktionen:

Thread (Java 2 Platform SE 5.0)
Thread (Java 2 Platform SE 5.0)

die alle Exceptions auffangen, die nicht irgendwo anders aufgefangen wurden. Ich habe das aber noch nie benutzt.

Slawa

 

[Gast2]

Mit einem "allumgreifenden try-catch-block" kommst du nicht weiter.
Ich würde mir mal log4j anschauen, das gefällt mir persönlich ganz gut. auf dieser Seite findest du ein paar Beispiele:
Logging mit Log4j

 

[dermoritz]

danke mal bis hier, insbesondere "setDefaultUncaughtExceptionHandler" ist eben genau das was ich brauche. Hat das schon jemand mal probiert? Eventuell sogar mit logging?

EDIT: ich hab mir mal im Java-Insel-Buch den Abschnitt durchgelesen. Ich glaube "(setDefault)UncaughtExceptionHandler" hilft nur etwas wenn der Thread durch eine Exception beendet wird. Dann kann man mit hilfe dieses Konstrukts noch einen halbwegs kontrollierten Abgang gewährleisten.

In meinem Fall geht es aber um "normale" Exception, bzw. in einer Swinganwendung stören ja Exceptions den Thread gar nicht (Das Fenster bleibt meist offen) und wenn man so eine Anwendung nicht in einer Konsole startet merkt man oft gar nix von den Exeptions! Aber ich will etwas von denen merken.

 

[KrokoDiehl]

Hat das schon jemand mal probiert? Eventuell sogar mit logging?

Ja. Aber ich habe auch log4j dafür benutzt und das über einen eigenen Appender (geerbt von der log4j-Klasse) verwendet, um es in einer JTable anzeigen zu lassen.
Ich weiß nicht ob es der Königsweg ist, aber es geht so wie ich's wollt

 

[dermoritz]

Kroko was mich interessiert ist: wie kommt man an diese Exceptions ran die ansonsten nur in der Konsole zu sehen wären?

 

[Gast2]

wie kommt man an diese Exceptions ran die ansonsten nur in der Konsole zu sehen wären?

Du kannst dir einen eigenen System.out bzw. System.err setzen (System.setOut(...)). So kommst du dann auch an alle Fehlermeldungen die dir sonst nur auf die Konsole geschrieben würden.
Ich habe es bei mir so gemacht dass ich über diesem Weg die Fehlermeldungen dann an log4j übergeben habe. Dort habe ich dann drei Appender konfiguriert (DaylyRollingFileAppender, ConsoleAppender und nen eigenen ums gefärbt in eine JTextArea zu schreiben.

 

[KrokoDiehl]

Die Sache ist ja, dass du dich an vielen Stellen selbst um eine Ausnahmebehandlung kümmern musst. Allein schon wenn man was mit Dateien macht kommt man um ein

catch (IOException)

oder

throws IOException

nicht umhin.
An jenen Stellen muss man eben schauen, wie man die entstandenen Ausnahmen weiterleitet / -behandelt.
Ansonsten gibt es den bereits erwähnten UncaughtExceptionHandler, den man an die ThreadGroup hängen kann. Der krieg die übrigen Ausnahmen mit.

Bei einer log4j Lösung ist das Bequeme, dass man direkt darüber die Ausgaben/Protokolling machen kann.

 

[dermoritz]

Wie gesagt mir geht es um Ausnahmen die man vergisst, die aber das System nicht abschießen. Z.b. einen Button der bei Knopfdruck was machen soll aber stattdessen eine Exception wirft. Falls man die Gui nicht in einer Konsole gestartet hat sieht man diese Exception nicht und der Knopf macht einfach nix.
Diese Teile muss man erstmal fangen - wie ich uncaughtException-dingens verstehe hilft das nur falls der Thread sich auf Grund einer Ausnahme beendet - ist das so?
Falls das So ist wäre eben die Frage wie ich an die Ausnahmen komme (was ich dann mit Ihnen anstelle ist hier nicht die Hauptfrage): Also soll man alles was in der main ist in einen try-catch-block packen? Oder nur den Aufruf der Gui oder eben dieses "runnable" -Konstrukt der Swing Gui?
Ich kann mir irgendwie nicht vorstellen, dass es da kein Best Parctice gibt (bei jeder Gui will man doch eigentlich sicher sein, das Ausnahmen nicht in der nicht vorhandenen Konsole verschwinden?!)

 

[KrokoDiehl]

Der UncaughtExceptionHandler tut schon das, was der Name suggeriert. Für dein Vorhaben ist er bestimmt geeignet. Ich habe ihn auch benutzt und bekomme (in Zshg mit dem Logging) nun alle Ausnahmen darüber und finde in der Stdout keine mehr.
Es gibt ja auch die statische Methode

set[B]Default[/B]Uncaught...()

. Das gilt dann für alle zukünfigen Threads.
Natürlich kann ein Thread aufgrund einer Ausnahme beendet werden, das ist in der EventQueue völlig normal, wenn ein Ereignis bearbeitet wird, dabei aber eine Ausnahme fliegt. Damit ist die Bearbeitung auch zu Ende.

Ansonsten: Probier es aus

 

[Noctarius]

Wenn man alle Exceptions loggen will egal ob Caught oder Uncaught sollte man auf AOP zurückgreifen.

 

[dermoritz]

Dann mal vielen Dank an alle! Nun hab ich glaube alle Bausteine zusammen.

AOP - Aspect Oriented Programming? - schau ich mir frühestens beim nächsten Projekt an. Wüde sich dieser Ansatz lohnen wenn das einzige "cross cutting"-Element das Logging ist?

 

[Noctarius]

Kommt drauf an. Ich hab immer generelles Logging in der Anwendung per log4j. Wenn ich aber spezielle Sachen abfragen will, z.B. Aufruf-Reihenfolge von Methoden oder so ähnliches greife ich auf AOP zurück, welches nachträglich schnell per Config an jedem Methodenaufruf gehangen werden kann.
Kommt halt drauf an was du mit Logging meinst. Standard-Logging der Anwendung würde ich auch mit log4j oder anderen Frameworks erledigen, Debug-Logging ist mit AOP sicher der bessere Weg (zumal kein Code in der Anwendung dafür hinterlegt werden muss).
Bei (uncaught) Exception-Logging an ist das meiner Meinung nach schwieriger, das ist so ein Zwischenfall. AOP ist dann Klasse wenn du eine / mehrere Sorten Exceptions explizit fangen willst. Quasi alles abgeleitet von RuntimeException oder alle SQLExceptions oder oder oder. Nicht immer will man schließlich wirklich alles fangen und loggen.

 

[dermoritz]

so inzwischen hab ich das mal probiert (uncaughtExdeptionHandler + java logging) - funktioniert einwandfrei. Danke nochmal!
AOP werde ich auch im Auge behalten - das derzeitige Projekt ist dafür noch nicht geeignet. Noch eine Frage zu log4j was ist daran besser (falls überhaupt vergleichbar) als java.util.logging.logger?

 

[maki]

Noch eine Frage zu log4j was ist daran besser (falls überhaupt vergleichbar) als java.util.logging.logger?

java.util.logging.logger ist ein Abklatsch von log4j, kann nicht soviel, speziell im Enterprise Bereich ist log4j ein Quasi Standard.
Ansonsten gibt es noch SLF4J, commons-logging, etc. pp., komt imho aber alles nicht an log4j ran.

 

[Noctarius]

Sollte SLF4J nicht mal der Nachfolger von log4j werden? (sind doch auch die selben Leute glaub ich)

 

[maki]

k.A. ob SLF4J der Nachfolger werden sollte, verwenden tue ich es nur wenn nötig, weil zB. Spring auf commons.logging beharrt.

Irgendwer hat mal gesagt dass diese ganze "Java Logging Szene" ganz schön lächerlich ist

 

[dermoritz]

danke nochmal - für mich heißt das solange java.util.logging reicht were ich das benutzen.