2010-02-09 13 views
8

Ich arbeite gerade an einem Projekt und bin auf ein bisschen Kopfzerbrechen gestoßen. Ich programmiere seit etwa zwei Jahren in Java und habe Ausnahmen behandelt, aber nie richtig verstanden.Wo ich mit einer Exception umgehen kann

In meiner jetzigen Situation Ich habe meine Hauptmethode bekam, die eine Klasse

WikiGraph wiki = wiki = new WikiGraph(getFile()); 

Der Wikigraph Konstruktor nimmt einen Dateinamen, die ich über eine DialogBox im getFile() Verfahren erhalten initialisiert.

Der Konstruktor für Wikigraph ruft dann eine Methode namens loadfile(filename), die versucht, die angegebene Datei zu laden und zu analysieren.

Die loadfile() Methode ist, wo ich einen IncorrectFileTypeError werfen werde.

Meine Frage ist, wo soll ich damit umgehen?

Im Moment arbeite ich fangen sie in der loadfile() Methode

try { 
    //load file 
} catch (IncorrectFileTypeError e){ 
    System.out.println("Incorrect file type: "+filename+": "+e.getMessage()); 
    throw new IncorrectFileTypeError(); 
} 

Aber ich es auch wie so bei der WikiGraph Initialisierung fangen:

while(wiki==null){       //While There is no valid file to add to the wikigraph 
    try { 
     wiki = new WikiGraph(getFile()); //Try to load file 
    } catch (IncorrectFileTypeError e) { //If file cannot be loaded 
     JOptionPane.showMessageDialog(null, "Incorrect File Type Given. Please Choose another file."); //Display error message 
     getFile();       //Prompt user for another file 
    } 
} 

Nun ist die Art, wie ich den Fehler behandelt haben der richtige/beste Weg? Oder sollte es anderswo behandelt werden, wie in der getFile() Methode?

EDIT: Ich nehme an, ich sollte das Dateiproblem etwas klarer machen. Die Dateierweiterung basiert nicht auf dem IncorrestFileTypeError und kann daher ein irreführender Fehlername sein. Die angegebene Datei kann so ziemlich jede Erweiterung haben, deren Inhalt gut geformt sein muss.

+0

Dies ist eine subjektive Ansicht der Handhabung von Ausnahmebehandlung. Ich würde dies in das Community-Wiki setzen – Ascalonian

Antwort

4

In diesem Fall würde ich vermeiden, Ausnahmen als Ihre primäre Methode zum Umgang mit falschen Dateitypen zu verwenden. Wenn eine Ausnahme regelmäßig durch Benutzereingaben ausgelöst werden kann, sollte sie nicht als Ausnahme behandelt werden. Hier ist der Ansatz, den ich nehmen würde:

  • Überprüfen Sie den Dateityp und warnen Sie den Benutzer, wenn der Dateityp ungültig ist, durch Standard-Kontrollfluss. Sie könnten eine statische Methode in WikiGraph wie IsFileValid (Dateiname) in Betracht ziehen
  • In der WikiGraph-Initialisierung, werfen Sie eine Ausnahme, wenn der Dateityp ungültig ist.
  • Dieser Ansatz gibt Ihnen das Beste aus beiden Welten - Sie haben die Möglichkeit, Benutzer zu warnen, wenn ungültige Daten zur Verfügung gestellt werden, während aus Sicht von WikiGraphs die Richtigkeit der Informationen gewährleistet ist. Es gibt Entwicklern, die gegen einen WikiGraph arbeiten, die Möglichkeit, sicherzustellen, dass ihre Eingaben gültig sind, ohne dass eine Ausnahmebehandlung erforderlich ist.

    +0

    Ah ja, aber meine Dateierweiterung ist nicht eingestellt. Ich erhielt eine IDX-Beispieldatei zur Verarbeitung. Es könnte .txt oder irgendetwas sein, also kann ich nicht anhand der Dateinamenserweiterung überprüfen, nur auf den Inhalt der Datei. Die isFileValid() - Methode müsste dann die Datei analysieren, um zu prüfen, ob sie gültig ist. Da dies in der loadfile() -Methode geschieht, sollte ich sie nicht einfach dort abfangen. –

    +0

    Ja, leider können solche Probleme auftreten. Ich würde immer noch empfehlen, auf der UI-Ebene ohne Ausnahmen zu versagen, wenn es eine relativ einfache Prüfung für die Datei gibt (dh Überprüfung der Kopfzeile), aber für kompliziertere Prüfungen müssen Sie möglicherweise loadfile()) einchecken –

    +1

    @Chris: Ich bin nicht einverstanden. Wenn die Datei ungültig ist, kann die WikiGraph-Instanz, die sie erstellen möchte, offensichtlich nicht richtig initialisiert werden. Teilinitialisierte Instanzen zuzulassen ist sehr gefährlich. Also würde ich den Konstruktor einfach die Ausnahme deklarieren lassen und dann einen try-catch um den Konstruktor setzen. Der Versuch würde den Benutzer natürlich immer noch auffordern. – sleske

    1

    Ich glaube nicht, dass es Sinn macht, es in loadfile zu fangen. Sie können immer noch eine Protokollnachricht schreiben (verwenden Sie System.err), tun Sie es einfach, bevor Sie die Ausnahme auslösen. Sie sind auf dem richtigen Weg mit dem Abfangen der Ausnahme, wo Sie tun können etwas darüber (in diesem Fall die Aufforderung erneut den Benutzer).

    +1

    +1 für "die Ausnahme abfangen, wo Sie etwas dagegen tun können", aber -1 für "Sie können immer noch eine Protokollnachricht schreiben". Bitte, * bitte *, nicht beide zu loggen und zu werfen (siehe zum Beispiel http://codemonkeyism.com/7-good-rules-to-log-exceptions/, "Log nicht und retrow"). Die Ausnahme * wird * irgendwo behandelt, und dort sollte die Entscheidung zum Protokollieren getroffen werden. Andernfalls erhalten Sie zwei Protokolleinträge für einen Fehler, was sehr verwirrend sein kann. – sleske

    +0

    Ich habe nie gesagt, erneut zu starten. Ich sagte Log "bevor die Ausnahme geworfen". In diesem Fall denke ich, dass Loadfile die einzige geeignete Ebene für die Protokollierung ist. –

    3

    Einer der Hauptvorteile von Ausnahmen besteht darin, dass sie Ihnen bequeme Mittel zum Behandeln einer Ausnahme geben, weit entfernt von der Stelle, an der sie auftritt. In Sprachen, die dies nicht unterstützen, müsste jeder Aufruf des Pfads den Rückgabewert überprüfen, brechen und zurückgeben, sodass Sie ihn manuell propagieren.

    Es ist sinnvoll, die Ausnahme zu behandeln, bei der Sie das Gefühl haben, dass Sie sie entweder wiederherstellen oder am besten melden und den Vorgang abbrechen können.

    Mein Verständnis ist, dass die Interaktion mit UI-Eingabe beginnt und dass, wenn der Dateityp unpassend ist, Sie nicht wirklich wiederherstellen können. Daher würde ich jede UI-Aufgabe, die die Datei initiiert hat, die Ausnahme abfangen, dem Benutzer melden, dass ein Fehler aufgetreten ist, und entweder abbrechen oder nach einer anderen Eingabe fragen.

    Bei einer zweiten Lesung scheint es, als würden Sie den Dialog öffnen, nachdem Sie bereits damit begonnen haben, das Diagramm zu erstellen. Ich persönlich möchte die UI-Interaktion isolieren. Ich würde daher persönlich zuerst alle Eingaben der Benutzeroberfläche bearbeiten, den erwarteten Dateinamen abrufen, überprüfen, ob er meinen Anforderungen entspricht, dem Benutzer Bericht erstatten, falls nicht, und nur weitermachen, wenn die Datei in Ordnung ist, und dann nur kritische und unerwartete Fehler melden.

    1

    Wenn das Problem ist, dass der Benutzer eine Datei des falschen Typs gewählt hat, dann denke ich nicht, dass Sie den Code überhaupt so weit gehen lassen sollten. Dies scheint nicht wirklich eine Ausnahme zu sein, sondern eher ein Pfad im Programm. Wenn der Benutzer einen falschen Dateityp ausgewählt hat, sollte er die Wahl haben, die Datei erneut auszuwählen. Offensichtlich sollten Sie die Auswahlmöglichkeiten im JFileChooser auf Dateien des richtigen Typs beschränken, wenn es so einfach ist, die Erweiterung zu betrachten.

    1

    Ich denke, das ist die Art von Situation, die geprüft Ausnahmen sind für (ob Sie damit einverstanden sind oder nicht.) Ich nehme an IncorrectFileTypeError erweitert Error? Erweitern RuntimeException wäre passender, und die Erweiterung IOException wäre noch besser, weil diese Art von Fehler durch gültige Benutzereingabe ausgelöst werden kann (dh den Namen einer Datei eingeben, die existiert aber den falschen Typ hat.)

    0

    Ich glaube Dieser Fehlertyp (IncorrectFileTypeError) kann im Benutzereingabeformular aufgelöst werden, wodurch ein unnötiger Roundtrip auf den Dateisystemdienst-Layer vermieden wird.

    Verwandte Themen