Stacktrace zeigt ...(Unknown Source)

TRaeger

Mitglied
Hallo,
Folgendes Problem:
Unser Programm wirft an einer Stelle innerhalb unseres eigenen Codes eine Exception. Beim Tester wird im StackTrace jedoch generell (unknown Source) ausgegeben, so das es schwierig wird, den genauen Übeltäter ausfindig zu machen.
Ich kenne mich jetzt mit den java-Interna noch nicht so doll aus, gibt es eine Option, die dazu führt das die jar-Files entsprechend gestript werden oder werden generell die .java-Quellen auf dem Rechner benötigt um diese Meldung zu umgehen?

Vielen Dank im voraus
Tilman (Räger)
 
Moin,

(a) eine Exception umgeht man nicht, sondern reagiert darauf!
(b) poste doch einfach mal den StackTrace ... so kann man nur rumraten!

Gruß Klaus
 
(b) poste doch einfach mal den StackTrace ... so kann man nur rumraten!
Hm ... er hat doch geschrieben dass der Tester einen StackTrace bekommt nur eben mit "unvollständigen Informationen". Um die Exception selbst geht es ihm ja nicht.

(Soweit ich weiß: ) Der Tester braucht auch die Source Dateien um bei Exception eine vollständige Information (Datei + Zeile) zu bekommen.
 
Man kann Debug-Infos inkludieren, zumindest maven und Gradel machen das default auch. Für die Standard-Lib sind die aber glaub ich nur beim JDK vorhanden.

Wie baut ihr denn?
 
Also bei einer nicht obfuskierten .jar bekommt man mindestens Klasse und Methode wo es abtaucht. Das sollte bei übersichtlich programmierten Code eigentlich auch reichen.

Gruß

Claus
 
Also bei einer nicht obfuskierten .jar bekommt man mindestens Klasse und Methode wo es abtaucht. Das sollte bei übersichtlich programmierten Code eigentlich auch reichen.

Gruß

Claus
...und wenn Man das fortführt: Bei gut geschriebenen Programmen gibts keine Fehler.

Aber damit dreht man sich irgendwie im Kreis 😉
 
Hallo,

wie Joose richtig erkannt hat, mich interessiert weniger die einzelne Exception (die sind z.T. selbst geworfen und ich weiß warum und wo sie geworfen wurden) sondern der Stacktrace. Leider sind unter den ca. 100 Exceptions, die bei der Ausführung des Programms im Laufe der Zeit geworfen werden, auch die eine oder andere Nullpointer-Exception dabei. Bei einer normalen Anwendung ist das schon ärgerlich, aber hier geht es um eine embedded Anwendung die Teil eines größeren Pakets ist (mit diversen externen Geräten etc.), debuggen ist also schwierig. Ausserdem ist nicht klar, ob der Nullpointer nun ein Fehler ist oder aufgrund besonderer Umstände regulär auftreten darf (und entsprechenden abgefangen werden müsste). Hier wäre der Stacktrace also extrem hilfreich.
Dummerweise bekommen wir (auf den Entwicklungsrechnern) zwar bei allen Exceptions einen brauchbaren Stacktrace, aber können leider den Fehler nicht reproduzieren. Das gleiche auf den uns zur Verfügung stehenden Testgeräten. Auf dem eigentlichen Testsystem gibt es dann nur den verstümmelten Stacktrace.

Ich vermute mal, das irgendeine Option beim Erstellen der Software für das Target verhindert, das die entsprechenden Debug-Informationen mitgegeben werden. Diese Option (oder was es sonst verhindern kann (nachträglicher strip-Befehl o.ä.) interessiert mich.
z.I. : Die Anwendung wird unter Linux mit Eclipse / ant gebaut, Java-Version ist 8.x

Gruß
Tilman (Räger)
 
Regulär auftretende NPE? Das klingt ziemlich komisch...


Bei ant muss man das in javac-Tag extra angeben, musst du mal in die Doku gucken, irgendwas mit "debug" ist das 😉
 
javac.debug ist auf true gesetzt :-(
Irgendwelche möglichkeiten, den Code nachträglich zu strippen - oder Gründe, warum Java die Debuginformationen ignorieren könnte?

Die in Frage kommenden Objekte werden aufgrund von den externen Geräten hereinkommenden Messages gesetzt - da ist es immer mal möglich, das eine Message nicht gesendet wurde und entsprechende Objekte dann null sind. Wenn ich dann ohne vorherige Prüfung auf diese Objekte zugreifen will bekomme ich halt eine Nullpointer-Exception. Sicher, das Auslassen der Prüfung könnte man als Programmierfehler betrachten, aber häufig ist die Herleitung nicht so ganz einfach, das man sagen kann, das kann null werden und das nicht. Da fliegt einem schon mal was um die Ohren - vor allem, wenn man es mit jahrealtem Code, an dem sich schon ein Haufen Programmierer versucht hat, zu tun hat (Viele Köche ....)

Tilman
 

Zurück
Oben