# Alle Vorhandenen Variablen ausgeben...



## noetig (11. Mrz 2010)

Gibt es so ne Art Debug Modus, in dem ich einfach alle zu dem Zeitpunkt vergebenen Variablen über die Console ausgeben kann? Ich habe das Problem, dass ich Testroutinen habe und diese nicht einsehen kann. Und würde mir gerne anzeigen was als Eingabe werte gemacht wurden.


----------



## faetzminator (11. Mrz 2010)

Alle Variablen? Nein, so etwas gibt es nicht. Höchstens per Reflection alle Instanzvariablen, aber das geht wohl in die falsche Richtung.
Doch nur die Eingabewerte? Lass sie dir manuell ausgeben.


----------



## Tomate_Salat (11. Mrz 2010)

Nun ja, jede gescheite IDE hat einen DebugModus in dem du alle Relevanten Variablen bekommst. Aber komplett alle...Meines Wissens nicht standartmäßig und auch unnötig, da die Flut an Informationen hier auch für den Programmierer wohl zu viel wären. Vor allem: Manche Variablen kommen öfters als einmal vor. Z.B. [c]i[/c] benutze ich für fast jede For-Schleife. Dazu kommen Variablen die nur temporär sind. Z.B. beim befüllen einer Tabelle mit Werten aus einer Datenbank.

Also wofür brauchst du JEDE Variable?! Wieso tut es hier kein normaler Debugger?


----------



## nrg (11. Mrz 2010)

die beste option ist, wie tomate schon gesagt hat, eine ide. allgemein helfen aber auch ganz normale System.out.println. gerade bei rekusiven Geschichten ist das manchmal genauso hilfreich wie eine gute ide. Wenn du irgendeinen case ausschließen willst, der einfach nach der programmlogik nicht eintreten darf, helfen auch assertions (nehm ich aber eher seltener). Im Grunde sind assertions nur in "größeren Dimensionen" sinnvoll, weil sie eben explizit aktiviert werden müssen. D.h. sie können im Endprodukt enthalten bleiden (consolenausgaben natürlich nicht - dem kunden interessiert nicht, wie hoch z.b. die variable i bei einer iteration o.ä. ist).

grüße


----------



## Firestorm87 (11. Mrz 2010)

Je nach Umfang existieren hierfür auch sehr hilfreiche tools wie log4j, welche eben auch im Endprodukt enthalten bleiben können, da man den Grad der Informationen per properties-datei staffeln kann, so dass man während der entwicklung auch reine Informationen auf der Console mit ausgeben kann, während man beim kunden nur schwerwiegende fehler dann vll in eine datei schreiben lässt, um sie auswerten zu können.

Ansonsten für richtige Fehlerfindung geht nichts über einen guten Debugger...

/EDIT: Hier mal ein BSP:
11.03.2010 09:31:19,845 ERROR AngemeldeterAnwender - blablabla
11.03.2010 09:31:45 FINE findLibrary(String) "Searching library "xxxx""
11.03.2010 09:31:45 FINE findLibrary(String) "Library "yyyy"

Das erste würde man beim Kunden vll noch mit loggen, den Rest natürlich nicht


----------



## noetig (12. Mrz 2010)

Tomate_Salat hat gesagt.:


> Nun ja, jede gescheite IDE hat einen DebugModus in dem du alle Relevanten Variablen bekommst. Aber komplett alle...Meines Wissens nicht standartmäßig und auch unnötig, da die Flut an Informationen hier auch für den Programmierer wohl zu viel wären. Vor allem: Manche Variablen kommen öfters als einmal vor. Z.B. [c]i[/c] benutze ich für fast jede For-Schleife. Dazu kommen Variablen die nur temporär sind. Z.B. beim befüllen einer Tabelle mit Werten aus einer Datenbank.
> 
> Also wofür brauchst du JEDE Variable?! Wieso tut es hier kein normaler Debugger?



Problem, bei mir werden "inoffizielle" Testdaten in mein Programm geschmissen. Somit weiß ich nicht was eingegeben wurde wenn ein Fehler kam. Lokal teste ich mit Eclipse, aber da habe ihc die TestDateien nicht :/


----------



## 0x7F800000 (12. Mrz 2010)

noetig hat gesagt.:


> Problem, bei mir werden "inoffizielle" Testdaten in mein Programm geschmissen. Somit weiß ich nicht was eingegeben wurde wenn ein Fehler kam. Lokal teste ich mit Eclipse, aber da habe ihc die TestDateien nicht :/


Diese Testserver der Uni's jaja  Da sind die Möglichkeiten zum Debuggen tatsächlich sehr beschränkt... 
Also, mit System.out.println() müsstest du da doch einigermaßen klarkommen, das liefert der Server doch in Textform zurück? Ansonsten kannst du dir die fehlermeldungen vielleicht per email schicken 

Wenn du System.out.println() irgendwie verwenden solltest, würde ich empfehlen, da irgendeine zentrale methode dazwischenschalten (die System.out.println wrappt), damit man das gelaber schnell abschalten kann (das mögen die Testserver wohl nicht, weil sie dann lauter Ausgaben bekommen, mit den sie nicht rechnen)

PS: meine güte, schreib dir doch selbst ein paar tests, räum alle Probleme weg, solange das Programm noch "zu Hause" ist, und nicht irgendwo auf dem testserver rumgeistert... Programm normal debuggen und eine korrekte Version hochladen wird ja wohl schneller gehen, als irgendwelche Stunts auf diesem Server zu machen...


----------



## Tomate_Salat (12. Mrz 2010)

Im Zweifelsfalle: einfach mitloggen, wie 0x8F90* schon sagte: entweder per email oder logging-Datei. Bei Großprojekte schalte ich sogar meistens eine eigene Konsole zwischen rein die Exceptionhandling unterstützt. Diese kann ein+ausblenden und loggt alles mit was ich will. Kommt ein log vom Typ: Error erstellt er mir automatisch eine LOG-Datei mit allen vorgängen. 

Finde ich speziell dann nützlich, wenn das Programm später beim Kunden aufm rechner läuft und man bestimmtes verhalten nachvollziehen will. Da kann ich mich sehr gut an den Log-Files orientieren. Zumal meine Log-Files html-Dateien sind mit farblicher gestaltung.


----------

