2016-08-01 8 views
0

Ich habe eine Konsolenanwendung, die mit der Hardware interagiert. Meine Idee war, alle Ausnahmen mit ihren Stacktraces zu protokollieren, so dass wertvolle Informationen nicht verloren gehen, da keine Pipe zu einer Datei vorhanden ist.So behandeln Sie Ausnahmen in der Konsolenanwendung

Aber wie mit dem Speicherort dieser Datei umgehen? Ich kann nicht jedes Mal nach einem Pfad fragen.

Deshalb dachte ich, nur die Datei neben der ausführbaren Datei. Aber kann nicht sicher sein, wo die App wohnen wird. Und ich habe nicht eine eindeutige Antwort auf „wie man den App Weg“

I found:new java.io.File("").getAbsolutePath(); aber keine Erklärung, wie das funktioniert gefunden.

And:getClass().getProtectionDomain().getCodeSource().getLocation().getPath(); Aber die op sagte diese nur kann Arbeit. Gibt es eine andere Möglichkeit, das ErrorLogging zu handhaben/eine sichere Methode, um den App-Pfad zu erhalten?

+2

Wie wäre es mit einem der Standard-Logging-Frameworks und folgen Sie deren Dokumentation. Sie könnten z.B. Eine Kombination aus slf4j und Logback und der Konfiguration des letzteren definiert, wohin die Logs gehen, in eine Datei, in eine ElasticSearch-Instanz oder in das Terminal. Wenn Sie dann nach einer Datei suchen, kann dies entweder absolute oder relative Position sein ... –

+0

ein relativer Pfad zur App oder zum aktuellen Verzeichnis? – gismo

+1

Dies ist die Frage zu dem bestimmten Protokollierungsrahmen, den Sie verwenden. In Bezug auf Logback wird die folgende Antwort helfen: http://stackoverflow.com/questions/16480052/is-there-a-way-in-logback-xml-to-specify-file-log-destination-through-classpath –

Antwort

1

Der Standardansatz für das Protokollieren von Ausnahmen in allen Arten von Anwendungen besteht darin, eines der Standardprotokollierungsframeworks zu verwenden und seine Konfiguration extern für die Anwendung zu definieren. Ausnahmen werden als protokolliert und entsprechend behandelt.

Man könnte z.B. slf4j (Logging-Schnittstelle) zusammen mit Logback (die passende Implementierung), aber andere werden auch gut.

Wenn Sie den Code zu schreiben, ist die Schnittstelle zum Zeitpunkt der Kompilierung verfügbar sein muss, da der Code programmiert und kompiliert ist dagegen:

import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 

public class MyClass { 

    private static final Logger LOGGER = LoggerFactory.getLogger(Myclass.class); 

    public void method() { 
    try { 
     ... 
    } catch (IOException ex) { 
     LOGGER.error("method failed to do what was expected: {}", ex); 
     throw ex; 
    } 

Eine besondere Implementierung muss zur Laufzeit zur Verfügung gestellt werden (zB zu einer jar während des Paketierens) oder zur Laufzeit zum Klassenpfad hinzugefügt werden.

Als nächstes wird eine Konfiguration der jeweiligen Implementierung muss passend zur Laufzeit zur Verfügung gestellt werden, die für logback wie folgt aussehen:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration scan="true"> 
    <appender name="FILE" class="ch.qos.logback.core.FileAppender"> 
    <file>myapp.log</file> 
    <encoder> 
    <pattern>%logger{35} - %msg%n</pattern> 
    </encoder> 
</appender> 

    <root level="error"> 
    <appender-ref ref="FILE"/> 
    </root> 
</configuration> 

Weitere Informationen siehe unter:

+0

Sie scheinen sich zu bemühen, die in Java SE integrierte Protokollierung zu vermeiden (http://docs.oracle.com/javase/8/docs/api/). Java/util/Protokollierung/Paketzusammenfassung.html), das so gut ist wie all diese anderen Optionen und hat den Vorteil, dass keine zusätzlichen Bibliotheken benötigt werden. – VGR

+0

Nein, ich mache diese Anstrengung nicht. Ich benutze das Obige als ein Beispiel, um die tatsächliche Antwort zu erklären (das heißt "ein Protokollierungs-Framework"), nur weil dieses Setup das ist, was ich in einer Reihe von Projekten erlebt habe und was de facto zumindest ein Industriestandard war vor kurzem. Bitte schlagen Sie eine Änderung vor, wenn es eine bessere Lösung gibt, während Sie sich an ein Protokollierungs-Framework halten. –