Exceptions ohne Zeilennummer (Unknown Source)

[Gast]

Ich bekomme bei Exceptions aus meinen eigenen Codestellen leider keine Zeilenangaben mitgeliefert. Dadurch fällt es mir schwer den Fehler zu lokalisieren. Das untere Beispiel zeigt den Stacktrace den ich bekomme. Die oberste Methode ist von mir, die darunter liegenden sind extern und liegen auch in einem eigenen Verzeichnis. Bei meiner Methode steht hinten in Klammer "Unknown Source", bei den anderen folgen exakte Zeilenangaben zum Code. ???:L

java.lang.NullPointerException
        at testproject.TaskManager.getTask(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        ...

Weiß jemand wie ich auch hier die verursachende Zeile angezeigt bekommen kann? Ich habe das Problem bei meinem Tomcat 4.1.30, bin mir aber nicht sicher ob es sich um ein Tomcat- oder ein Java-Problem handelt. Ich habe jetzt schon stundenlang im Netz nach Lösungen gesucht :### und war leider nicht erfolgreich. In meiner Entwicklungsumgebung Eclipse bekomme ich die genauen Quellenangaben übrigens korrekt zurück, aber bei einem Standalone-Tomcat nicht.

Danke für eure Hinweise!

 

[Beni]

Falls getTask nicht allzugross ist, kannst du ja ein paar "System.out.println( zeilennummer )" einbauen. Wenn dann plötzlich nicht mehr alle Zeilen ausgegeben werden...

Oder du setzt ein Haltepunkt mit einem Debugger, und schaust gleich zu, was in der Methode alles passiert.

 

[Gast]

Danke für die rasche Antwort!
getTask ist nur ein Beispiel. Es gibt auch einige sehr lange Methoden in denen ich mit dem gleichen Problem zu kämpfen habe. Das Problem wirkt sich auch vorallem dann aus, wenn während des produktiven Betriebes ein Fehler auftritt, weil ich beim Entwickeln ohnehin mit Eclipse die Zeilennummern angezeigt bekomme. Es handelt sichjetzt also nicht um einen konkreten Fehler den ich in getTask finden muss, sondern um den ersten Schritt bei der Indentifikation bestehender Fehler im laufenden System. Im Produktivbetrieb möchte ich keine System.out einfügen, denn sonst werden die Ausgaben zu unübersichtlich.

 

[Beni]

Tja, mit Tomcat kenn ich mich nicht aus.

Vielleicht für ein anderes mal, mit dem Package java.util.logging kann man den Programmfluss ein bisschen verfolgen...

 

[bygones]

schau doch mal in die logs von tomcat ob du da mehr findest... ansonsten würde ich auch noch log4j empfehlen damit kannste gemütlich und angenehm loggen

 

[Gast]

Danke für die Hinweise. log4j hab ich schon im Einsatz. Damit schaffe ich es auch den Fehler einigermaßen einzugrenzen, aber die Unsicherheit ist dennoch ziemlich groß, weil ich ziemlich viel Code habe und nicht so viele Ausgaben in den Code geben möchte. Das logfile wird schon jetzt in kürzester Zeit riesengroß. Eine NullPointerException kann ja auch nahezu überall auftreten. Am besten wäre mir geholfen wenn bei der Exception die Zeilennummer dabei stünde. Oder gibt es da Möglichkeiten mit den logging-Tools, die ich noch nicht kenne? :?: Würde mich interessieren.

 

[bygones]

nicht das mir bekannt ist...

wenn die Methode zu groß ist würde ich sie in kleinere untermethoden packen und dann nochmal debuggen.....

was anderes würde mir in dem fall nicht einfallen !

 

[Illuvatar]

Kompilierst du zufällig mit -g:none?

 

[Gast]

Bingo, das war's! Herzlichen Dank!
Ich verwende Ant für's compilieren und habe nicht gewusst, dass das dort standardmäßig mit -g:none compiliert wird, abgesehen davon, dass ich -g:none garnicht kannte. Also wieder was interessantes dazugelernt. Danke nochmal an alle und besondern Dank für den entscheidenden Hinweis!!! :toll: