Ich habe kürzlich einen Fehler gefunden, der eine NullPointerException verursacht. Die Ausnahme wird mit einer Standardanweisung slf4j abgefangen und protokolliert. Kurzer Code unten:

for(Action action : actions.getActions()) {
    try {
        context = action.execute(context);
    } catch (Exception e) {
        logger.error("...", e);
        break;
    }
}

Wie Sie sehen können, nichts Besonderes. Von allen Ausnahmenprotokollierungsanweisungen, die wir haben, gibt nur diese eine Stapelablaufverfolgung nicht aus. Es wird nur die Nachricht (dargestellt als "...") und der Name der Ausnahmeklasse (java.lang.NullPointerException) ausgegeben.

Da der Stack-Trace für eine Ausnahme verzögert geladen wird, dachte ich, dass möglicherweise ein Problem mit der Neuanordnung von Befehlen vorliegt, und entschied mich, e.getStackTrace () vor der Protokollanweisung aufzurufen. Das machte keinen Unterschied.

Also habe ich mich entschlossen, mit aktiviertem Debug-Agent neu zu starten. Da ich mich jedoch selbst an den Prozess angeschlossen habe, habe ich festgestellt, dass jetzt die Stapelspuren gedruckt werden. Die Anwesenheit des Debug-Agenten führte also eindeutig dazu, dass einige zusätzliche Debug-Informationen verfügbar wurden.

Ich habe seitdem die Ursache der Ausnahme behoben. Aber ich möchte erfahren, warum der Stack-Trace ohne Debugger nicht verfügbar war. Weiß jemand?

Klärung:Dies ist kein Protokollierungsproblem. Stellen Sie sich dieselbe try / catch-Klausel vor, aber im catch drucke ich den Wert von:

e.getStackTrace().length

Ohne einen Debugger gibt dies '0' aus, mit einem Debugger gibt es eine positive Zahl aus (in diesem Fall 9).

Weitere Informationen: Dies geschieht unter JDK 1.6.0_13, 64bit, amd64, Linux 2.6.9