debug output in java?

net 0

hallo,
sorry, das wurde sicherlich schon oft gefragt, aber ich konnte nix finden...
also folgendes:
in c gehen ja so tolle sachen wie

#ifdef DEBUG
#define DPRINT(x) puts(x)
#else
#define DPRINT(x) 
#endif

damit debugausgaben nicht in die release-version reincompiliert werden.
wie macht man das in java?

Gregor

Debugausgaben welcher Art?

net 0

Gregor schrieb:

Debugausgaben welcher Art?

ein einfaches 'System.out.println()' in der konsole wär gut, das in der release-version nicht mehr vorhanden ist.

btw:
was mir einfällt... könnte man sowas mit einer konstanten machen (final boolean z.b.) die in der ausgabefunktion abgefragt wird? wenn das ergebnis 'false' ist, würde der compiler das wegoptimieren? oder mit fehlermeldung 'unreachable code' abbrechen?
ich probier's mal aus...

Gregor

Meine Frage bezog sich auf die Semantik der Debugausgabe.

net 0

Gregor schrieb:

Meine Frage bezog sich auf die Semantik der Debugausgabe.

uhmm??
vielleicht habe ich mich zu undeutlich ausgedrückt. also ich will sowas:

irgendwo im code (debug modus):

...  // anweisungen
...  // anweisungen
debugOut ("eine ausgabe in der konsole ähnlich System.out.println");
...  // anweisungen
...  // anweisungen

soll, wenn man es im release-modus compiliert so aussehen

...  // anweisungen
...  // anweisungen
...  // anweisungen
...  // anweisungen

d.h. die dritte zeile (auf den ersten code bezogen) ist weg weil
z.b. der compiler sie wegoptimiert hat.
in c würde man das mit #ifdef... machen.
aber wie in java???

Gregor

net schrieb:

in c würde man das mit #ifdef... machen.
aber wie in java???

Ok, da du meine Frage immer noch nicht verstanden hast, hier mal die einfache Antwort. Eigentlich würdest du es in Java garnicht machen. Du würdest abhängig von dem, welche Semantik die Ausgabe hat entweder einfach nur einen Debugger benutzen, einen Profiler benutzen, die Logging-API benutzen oder ähnliches machen.

Wenn du ohne diesen Präprozessor-Mechanismus nicht leben kannst, dann besorg dir doch einfach einen Präprozessor für Java.

net 0

Gregor schrieb:

Ok, da du meine Frage immer noch nicht verstanden hast, hier mal die einfache Antwort.

na wenigstens hast du meine frage endlich verstanden

Gregor schrieb:

Eigentlich würdest du es in Java garnicht machen.

oder doch nicht

Gregor schrieb:

Du würdest abhängig von dem, welche Semantik die Ausgabe hat entweder einfach nur einen Debugger benutzen, einen Profiler benutzen...

und wie sag ich dem debugger, dass er an den gewollten stellen eine ausgabe macht? sag jetzt nicht, dass ich breakpoints setzen soll.

Gregor schrieb:

...die Logging-API benutzen...

und wie bekomme ich die aufrufe in die logging-api in der release-version weg?

Gregor schrieb:

...oder ähnliches machen.

aber was?

Gregor schrieb:

Wenn du ohne diesen Präprozessor-Mechanismus nicht leben kannst, dann besorg dir doch einfach einen Präprozessor für Java.

ja, danke. dem hinweis werde ich auf jeden fall nachgehen.

Gregor

net schrieb:

Gregor schrieb:

...die Logging-API benutzen...

und wie bekomme ich die aufrufe in die logging-api in der release-version weg?

Gar nicht. Warum auch? Als ob in der Release-Version keine Bugs auftreten könnten und man diese Informationen somit nicht brauchen könnte. Eine Log-Datei kann man immer gebrauchen, das sollte man nicht auf die Debug-Version begrenzen.

Gregor

net schrieb:

Gregor schrieb:

Du würdest abhängig von dem, welche Semantik die Ausgabe hat entweder einfach nur einen Debugger benutzen, einen Profiler benutzen...

und wie sag ich dem debugger, dass er an den gewollten stellen eine ausgabe macht? sag jetzt nicht, dass ich breakpoints setzen soll.

Du sollst Breakpoints setzen. Was glaubst du, wofür die da sind?

Gregor

net schrieb:

Gregor schrieb:

Eigentlich würdest du es in Java garnicht machen.

oder doch nicht

Doch, sicher. Ich habe es von Anfang an verstanden. Du versuchst deinen Code unlesbar zu machen, indem du das Verhalten deines Code von externen Schaltern abhängig machst, weil du ein künstliches Interesse an einer Extra-Version fürs Debuggen hast. Aus meiner Sicht ist das kompletter Unsinn. Du versuchst, dummes Verhalten aus anderen Sprachen auf Java zu übertragen. In Java macht man normalerweise keine Unterscheidung von Debug- und Releaseversion. Zumindest nicht auf Sourcecode-Ebene.

net 0

Gregor schrieb:

Du versuchst deinen Code unlesbar zu machen, indem du das Verhalten deines Code von externen Schaltern abhängig machst, weil du ein künstliches Interesse an einer Extra-Version fürs Debuggen hast. Aus meiner Sicht ist das kompletter Unsinn.

das ist kein unsinn.
ich habe ein java-programm, bei dem im hintergrund einiges abläuft und ich möchte sehen, dass es zu bestimmten zeitpunkten auch das macht, was ich erwarte.
ich kann es z.b. nicht mit debugger-breakpoints testen, da dann das programm stoppen würde und das verhalten wär komplett anders. einfache debug-ausgaben würden es jedoch nicht ausbremsen. und warum sollen die debug-ausgaben auch in der release-version zu sehen sein? da sind sie komplett überflüssig.
würde ich die logging-api benutzen, dann hätte ich nach einigen stunden eine riesengrosse log-datei. für's testen ok aber für die release-version nicht akzeptabel.
bleibt nur noch 'preprocessor'. ich werde mal den probieren: http://www.vortoj.com/sjpp/readme.html
aber...wieso verteufelst du das so?

Gregor

net schrieb:

ich habe ein java-programm, bei dem im hintergrund einiges abläuft und ich möchte sehen, dass es zu bestimmten zeitpunkten auch das macht, was ich erwarte.

Dann nutze assert.

net 0

Gregor schrieb:

Dann nutze assert.

hey, das ist eine gute idee!
jaja, ich muss noch viel lernen