2015-03-06 6 views
5

Ich weiß FileNotFound ist Checked Exception aber obwohl es ist, nur während der Laufzeit wird diese Ausnahme auftreten.Es ist eher wie Arithmetische Ausnahme (nicht abgehakt).Warum ist FileNotFoundException CheckedException?

Ob es aktiviert oder deaktiviert ist, die Ausnahme tritt nur zur Laufzeit auf.

Meine Frage ist, warum wir die FileNotFound/IO/DB bezogenen Stoffe als Checked Exception aufrufen?

Bitte teilen Sie mir Ihre wertvollen Gedanken :)

+0

'Arithmetische Ausnahme' ist nicht aktiviert? @Lathy –

+3

Sie implizieren, dass es Ausnahmen gibt, die außerhalb der Laufzeit passieren können? – John

Antwort

4

Ausnahmen treten immer nur zur Laufzeit auf, Es wird unterschieden, wenn eine Ausnahme behandelt wird.

Aktiviert oder deaktiviert bedeutet, dass die Datei zur Kompilierungszeit verarbeitet werden muss oder nur, wenn sie zur Laufzeit gefunden wird.

Wenn eine Ausnahme aktiviert ist, hat der Compiler eine Möglichkeit festzustellen, ob die Ausnahme auftreten kann oder nicht. und wenn Sie es kompilieren, werden Sie gezwungen, eine geprüfte Ausnahme zu behandeln, und dadurch werden die Chancen von Laufzeitausnahmen verringert.

Während der Dateiverarbeitung prüft der Compiler nicht, ob eine Datei vorhanden ist oder nicht, es überprüft nur, ob Sie fileNotFoundException bearbeitet haben oder nicht, weil die Wahrscheinlichkeit, dass diese Ausnahme auftritt, sehr hoch ist handle es in deinem Code. für arithmetische Ausnahme gibt es keine Möglichkeit, es während der Kompilierzeit zu finden. und so bleibt es unkontrolliert.

1

Alle Ausnahmen nur während der Laufzeit passieren kann :) Der Unterschied zwischen den Checked und Unchecked Ausnahmen ist, dass der Compiler zwingt Sie die checked diejenigen zu handhaben oder fügen Sie sie zu die Methodensignatur, was den Aufrufer dazu zwingt, das Gleiche zu tun (Handle/Retrow).

1

Sie haben es eine Checked Exception lassen, weil der Benutzer möglicherweise von dieser Ausnahme "erholen" kann, indem er es behandelt. Zum Beispiel kann der Benutzer ein anderes Verzeichnis angeben, falls diese Ausnahme auftritt.

3

NullPointerException oder ArithmeticException sollte in der Regel nicht in einem fertigen, korrekten Programm passieren. Sie können mit denen nur mit der Prüfung vor mit if umgehen, um zu sehen, ob Sie durch 0 oder ein Objekt teilen ist null und dann sind Sie sicher, diese Ausnahme wird nicht ausgelöst werden. Jedes Mal, wenn diese Ausnahmen behandelt werden, kann der Code weniger lesbar werden.

Jetzt könnten Sie argumentieren, dass Sie das gleiche für FileNotFoundException tun können, indem Sie nur überprüfen, ob die Datei existiert, bevor Sie etwas tun. Aber viele Konstruktoren oder Methoden, die eine File erwarten, unterstützen auch String, aus dem die Datei dann erstellt wird. Ich denke, es ist eine Frage, wo Sie die Linie zeichnen, wenn Sie immer nur die File Methode haben und nie auch String unterstützen, dann hätte ich es zu den ungeprüften auch hinzugefügt, denke ich.

Mit anderen Worten: Wenn ein FileNotFoundException geworfen wird, dann kann es das gewünschte Verhalten sein und den Fluss Ihres Programms treiben, aber NullPoinerException sollte wirklich nicht dafür verwendet werden.

0

Geprüfte Ausnahmen zwingen Benutzer, sie explizit zu behandeln. Sie werden für "behebbare" Ausnahmen verwendet, bei denen der Benutzer die Situation ordnungsgemäß behandeln kann.

Lassen Sie sich ein FileNotFound nehmen - es in der Regel wird ausgelöst, wenn die Datei nicht vorhanden ist, und unten ist ein verwandtes Programmierung Idiom:

FileInputStream fis = null; 
try { 
    fis = new FileInputStream(new File("")); 
} catch (FileNotFoundException e) { 
    e.printStackTrace(); 
} finally { 
    try { 
     fis.close(); 
    } catch (IOException e) { 
     e.printStackTrace(); 
    } 
} 

Die hier geprüfte Ausnahme zwingt mich, es in einem try/catch-Block zu erklären, wo kann ich die fis anmutig schließen, auch wenn es eine Ausnahme gibt.

Betrachten wir nun, dass FileNotFound eine Laufzeitausnahme ist, wird der Code hypothetisch wie folgt aussehen:

FileInputStream fis = null; 
fis = new FileInputStream(new File("")); 
fis.close(); 

Nun, wenn diese eine Laufzeitausnahme wirft - die Sie nicht bei der Kompilierung behandeln müssen, Ihre fis wird nicht anmutig geschlossen werden, und das ist ein Ressourcenleck.

Verwandte Themen