Logger - wie am schlausten?

[hdi]

Hey, wie realisiert man in Java am klügsten einen Logger?

ich möchte nach jeder wichtigen Bearbeitung einen Aufruf der eigenen Methode "log(String)" machen.
Diese MEthode soll beim Aufruf die Systemzeit ermitteln, und zusammen mit dem übergebenen String (Informationen) abspeichern.

Das ganze soll dann innerhalb meines Programms jederzeit abrufbar sein, man soll also z.B. auf den Button "Log" drücken können und dann kommt ein scrollbares Fenster, indem man alle nachrichten seit programmstart nachlesen kann.

Jetz also die Frage:

Mach ich das über eine temporäre datei, in die ich hineinschreib und die ich öffne, auslese und anzeige wenn man sich das ansehen möchte?
Oder gibt es da irgendwie tollere Möglichkeiten in JAva?

Danke

 

[SlaterB]

wenn Verlust bei Programmabsturz nicht schlimm ist und der Arbeitsspeicher bisher kein ernstes Thema ist,
dann kannst du auch die Informationen normal im Programm vorhalten,

in irgendeiner statischen Klasse in einer Liste,
da kannst du die Objekte dann sinnvoll aufbauen (Date, String, ..) und musst dich (noch) nicht mit Transformation in Datei und zurück ärgern

 

[maki]

Würde da log4j einsetzen, die Ausgaben in eine Datei speichern, die Anwendung kann ja den Inhalt der Datei anzeigen.

 

[hdi]

Danke, ich denke das ist echt am besten so, so viele Log-Nachrichten sinds eh nicht dass ich da n problem kriegen würde.
und wenns abstürzt is auch egal, das ist nur für mich während des programmierens als kleine debug-hilfe gedacht.

danke

 

[maki]

das ist nur für mich während des programmierens als kleine debug-hilfe gedacht.

In diesem Fall wäre echtes logging das einzig wahre:
log4j oder die Java logging API, ich bevorzuge ersteres.

 

[hdi]

hm, hab mir dieses log4j grad angekuckt.
ich weiss ja nicht.. ich hasse die java fehlerbehandlung, das is sowas von krass hässlich mit diesem try-catch mist,
und vorallem mein netBeans formatiert das auch noch so dass man gar nix mehr checkt wenn da so paar blöcke drin sind

Denke ich werde es nicht benutzen, ich vermeide es ja schon methoden zu benutzen die eine exception werfen aus o.g. grund. ich finde die java-fehlerbehandlung verunstaltet jeden source code

:bloed:

 

[maki]

Was hat Exceptionhandling mit log4j zu tun?

Die ist übrigens in C++ auch nicht "schöner", aber sowohl bei Java als auch bei C++ sehr nützlich, um nicht zu sagen vital
Kann sie auch kapseln.

Oder du lernst sie sinnvoll einzusetzen, "ein paar Blöcke drin sind" hört sich nicht wirklich danach an.

Aus Interesse, welche Sprache hat eine bessere?

 

[horschd77]

ich weiss ja nicht.. ich hasse die java fehlerbehandlung, das is sowas von krass hässlich mit diesem try-catch mist,

Alternative wäre throws Exception hinter den Methodenkopf zu schreiben, versaut die Code-Kunst nicht so sehr wie try-catch.

 

[hdi]

ja schon, allerdings ist es dann bei verschachtelten methodenaufrufen so, dass die auch alle diese Excpetion werfen müssen, und nicht nur diejenige, wo dann wirklich der entsprechende Code abgearbeitet wird.
find ich auch nich so geil.

naja, aber ich hab generell eine aversion gegen manche java-dinge, da man für die meisten sachen einfach 10 mal mehr zeilen code schreiben muss als bei anderen sprachen, zb c++. ich schätze aber dass es gewöhnungssache ist.
an den nervenden new-operator vor jedem kleinen statement hab ich mich auch schon gewöhnt

 

[Wildcard]

Alternative wäre throws Exception hinter den Methodenkopf zu schreiben, versaut die Code-Kunst nicht so sehr wie try-catch.

Die Regel für Exceptions ist einfach. Sie werden so lange weitergeworfen bis sie auf die erste Klasse treffen in der sie sinnvoll behandelt werden können. Dort werden sie dann gefangen.
Damit 'versaut' man sich keinen Quellcode, sondern es ist eines der wichtigsten Sprachfeatures von Java.

 

[SlaterB]

allerdings nur für höhere Anwendungen,
einen Anfänger interessieren sie zu 95% nicht, von daher ist das schon oft recht unglücklich,

wenn man allein nur an all das Datei lesen/ schreiben denkt,
wieviele Leute haben wirklich zu einer FileNotFoundException oder IOException irgendwas zu sagen?
da wäre für das Anfänger-Clientel eine RuntimeException wie die NullPointerException besser,
Code schön sauber, wenn Fehler ist merkt man das auch so
(jeder NullPointer fällt irgendwann auf )

wichtiges Sprachkonzept ja, aber leider zuviel des Guten am Anfang/ in den wichtigen Klassen

Gott sei Dank sind Hibernate-Exceptions inzwischen Runtime, das war vorher ein einziger Graus
(oder eine Wrapper-Operation die diese 'Information' umwandelt..)

 

[Wildcard]

Damit hast du zwar recht, aber macht es wirklich Sinn die API inkonsistent zu gestalten damit sie anfängerfreundlich wird?
Wenn man keine Ahnung hat was man da eigentlich tut genügt ja auch ein einfaches throws Exception und gut, was will man mehr?

 

[maki]

Aller Anfang ist schwer, da hilft nur üben, üben, üben... und weniger jammern

 

[SlaterB]

ich sehe da keine Inkonsistenz,
man muss ja nicht mal die vorhandenen Klassen ändern, sondern baut einfach eine zusätzliche dazu,
das ist überhaupt eines der allgemeinen Dinge in der API, alles so komplex zusammengebaut,

man stelle sich mal vor, wie leicht Java-Datei-Einlesen-Fragen-im-Forum zu beantworten wären,
wenn es

SimpleFileReader r = new SimpleFileReader(dateiPfad);
String line = r.readLine()

gäbe, mit Standard-Buffer, Standard-Encoding usw., Fehler als RuntimeException,

--------

oder der ganze JBDC-Aufwand:
schaut man sich irgendwelche Tutorials an, findet man nicht selten wüsten Code a la

try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
} catch(java.lang.ClassNotFoundException e) {
System.err.print("ClassNotFoundException: ");
System.err.println(e.getMessage());
}

try {
con = DriverManager.getConnection(url, userid, password);
} catch(SQLException ex) {
System.err.println("SQLException: " + ex.getMessage());
}

was soll man in den meisten Fällen nur sonst mit diesen Exceptions machen als sie mit Namen, Message und vielleicht Stacktrace auszugeben?
ohne die Standard-Exception-Behandlung wären es nur 2 Zeilen und man müsste sich nicht mal um den Abbruch der aktuellen Bearbeitung kümmern




das muss nicht mal nur für Anfänger gelten, ich selbst würde mir auch gerne sparen, überall entsprechende Wrapper-Klassen schreiben zu müssen..

---------


throws Exception ist leider nicht so leicht wie es aussieht,
in meinem Test-Programm kann ich es zwar schön an die main schreiben,
wenn man in einem größeren Programm aber aufeinmal irgendwo einfügt, dann hat man was zu tun,
und alle Operationen mit throws Exception sieht auch nicht mehr aus,

und dann noch ActionListener und Threads.run, bei denen das nicht erlaubt ist, Vererbungs-Ärger usw.
(durchaus alles noch vergleichsweise im Anfängerbereich anzusiedeln)

---------

sorry für zuviel Offtopic

 

[Janus]

in java soll man exceptions sinnvoll umgehen. das system ist gut durchdacht, nur leider wird es häufig mehr schlecht als recht umgesetzt. ich bekomm immer das kalte grausen, wenn ich LibX einsetze und an wirklich jeder methode ein "throws LibXException" deklariert ist.