# e.printStackTrace() nicht nur in der Console von Eclipse anzeigen lassen



## Lautsprecher (3. März 2006)

Hallo,
ich bin gerade auf einer schwierigen Fehlersuche in einem Programm, das bereits auf einem Computer im Betrieb arbeitet. Den Fehler konnte ich auch schon eingrenzen, da mir das Programm ein Logfile erstellt. Allerdings würde ich gerne noch genauere Infos über
e.printStackTrace() erhalten.
Das steht ja normalerweise während der Entwicklungszeit zur Verfügung (Eclipse -> Console).
Nur geht das ja im Betrieb nicht.
Ich habe mir überlegt vielleicht kann das e.printStackTrace() irgendwie über eine Messagebox ausgeben lassen? Aber leider funktioniet das auch nicht!!

Hat sonst jemand eine Ahnung wie mir e.printStackTrace() anzeigen lassen kann?

Sei es als Messagebox oder im Logfile, etc.

Hossa


----------



## Thomas Darimont (3. März 2006)

Hallo!

Wieso hast du im Betrieb keine Konsole? Kannst du das System in der Produktionsumgebung nicht einfach mal von der Konsole starten und entweder dort den Output anzegen lassen oder den Stdout/Stderr in eine Datei umleiten?

Na ja, wenigstens hast du jetzt gelernt, dass e.printStackTrace() auf die Konsole in Produktivumgebung nicht so der wahre Bringer ist ;-) Das nächste mal leitest du alle Ausgabeströme entweder in eine Datei um und/oder machst das ganze über eine (JVM/Environment)-Parameter Konfigurierbar...

Btw. wenn die Exception nicht behandelt werden würde, könntest du beim Thread in dem die Exception auftritt einen UncaughtExceptionHandler hinterlegen...:

```
Thread.currentThread().setUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler(){
            public void uncaughtException(Thread t, Throwable e) {
                JOptionPane.showMessageDialog(null, "ERROR",e.getMessage(),JOptionPane.ERROR_MESSAGE);
            }
        });
```
Das ließe sich beispielsweise mit AOP (AspectJ) nachträglich unterjubeln ohne den Code des anderen Systems anzufassen ;-)

Gruß Tom


----------



## takidoso (3. März 2006)

Halli und Hallo,
die von Tom vorgeschlagene Sache ist toll, wenn man mit neuerem Java arbeitet, kann es sein dass setUncaughtExceptionHandler() ab Java 5 geht?
Wenn man AOP verwenden kann, darf  (hängt vermutlich von der Einstellung des Unternehmes ab) dann ist das auch ganz prima.
Ich selbst mach dies jedoch im algemeinen so, dass ich den Exception-Trace (die nachricht hilft leider nur selten weiter einen Fehelr zu verstehen) in das dafür vorgesehene Log-File zu schreiben. Wichtig dabei ist natürlich, dass der Logger den man verwendet das auch unterstützt.
verwende datu von der geworfenen Exception ihre printStackTrace(PrintStream ps)
oder printStackTrace(PrintWriter pw) methode, wobei der Logger den Du verewndest natürlich seinen PrintStream oder PrintWriter zur Verfügung stellen muss, beispielsweise mit einer getPrintStream() Mehdode.

Takidoso


----------



## Thomas Darimont (3. März 2006)

Hallo!

na ja, auf diese Art und Weise muss man aber explizit bei jedem printStackTrace(...) Aufruf einen anderen OutputStream/Writer mitgeben... denke das ist nicht gerade bequem. Besser ist es dann die System.out / System.err umzulenken. Weiterhin war die Ausgabe der Message in einem JOptionPane ja nur ein Beispiel ;-)
Weiterhin kannst du AOP mit AspectJ zu Debugging zwecken auch so einsetzen, ohne anderen Code modifizieren zu müssen. Dazu musst du einfach die AspectJ-Runtime jars in deinen Classpath legen. Zusätzlich musst du dann  natürlich noch die Implementierung des passenden Logging/Errorhandling Aspects in den Classpath legen (Load-time Weaving sei dank ).
Damit habe ich schon sehr gute Erfahrungen gemacht...
Weithin klappt das auch noch mit Java 1.4 und sogar mit Java 1.3 ;-)


```
* @since 1.5
     */
    public void setUncaughtExceptionHandler(UncaughtExceptionHandler eh) { 
        checkAccess();
        uncaughtExceptionHandler = eh;
    }
```
-> Jo setUncaughtExceptionHandler gibts erst ab 1.5...

Gruß Tom


----------



## takidoso (3. März 2006)

Nachtrag ...
Es ist aus meiner Sicht wichtig grundsätzlich StackTraces in irgendeiner Form und sei es nur in einem Log auszugeben. Z.Z. bin ich in einem Unternehmen und betreue bzw. warte etwas von Zeit zu Zeit, was ich nicht selbst verbrochen habe und leider werden da sämmtlich Exceptions abgefangen in eine fachlichce Nachricht verpackt und dann ausgegeben, mit dem Zweifelhaften Erfolg lediglich Fachliche Meldungen zu haben ganz Stacktrace frei (grusel) ist ja nett dass der Anwender dann nichts sieht, aber bei technischen problemen, die nicht ausbleiben und dann eben auch nur fachlich angegeben sind, wobei es ja tatsächlich auch ein Programmfehler sein könnte, sucht man sich nacher dusselig und verbratzt unnötig Zeit, vor allem wenn man das Gesamtsystem nicht selbst geschrieben hat. Also als quasi Tip an alle, die es schätzen auch Entwickler, die nach einem kommen zu unterstützen: Bitte immer Stacktraces mit ausgeben und sei es dass sie lediglich in ein log geschrieben werden, sodass sie den Endanwender nicht verunsichern.

in diesem Sinne

Takidoso


----------



## Lautsprecher (3. März 2006)

Hallo,
danke Euch, ich werde mir das dann mal in Ruhe ab Montag reinziehen!!

Grüße


----------



## takidoso (3. März 2006)

Thomas Darimont hat gesagt.:
			
		

> Hallo!
> 
> na ja, auf diese Art und Weise muss man aber explizit bei jedem printStackTrace(...) Aufruf einen anderen OutputStream/Writer mitgeben... denke das ist nicht gerade bequem. Besser ist es dann die System.out / System.err umzulenken.



Ja das umlenken ist sicher auch ne feine Sache, aber wenn du ein System vorliegen hast, welches bereits einen Logging-mechanismus hat, und dies in dem vorgesehen System der Standard ist, dann sollte man sich halt, um des Entwcklerfriedens und der Einheitlichkeit, sei es auf Basis des Systems der gar des Unternehmens, entsprechend beugen. Ist halt ne Frage des etablierten vorliegenden Systems.

Ja ich weiß das mit dem Dialog war nur ein Beispiel, ich woltle Dich auch in keinster Weise kritisieren. Wollte nur eine Alternative zeigen, für den Fall, dass man eine Anwendung hat, die nicht GUI gestützt arbeitet.

Takidoso


----------

