Überprüfte und ungeprüfte Ausnahmen in Java verstehen

Question

Joshua Bloch in " Leistungsfähiges Java " sagte, dass

Verwenden Sie geprüfte Ausnahmen für wiederherstellbare Bedingungen und Laufzeit Ausnahmen für Programmierfehler (Punkt 58 in der 2. Auflage)

Mal sehen, ob ich das richtig verstehe.

Hier ist mein Verständnis einer geprüften Ausnahme:

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1. Handelt es sich um eine kontrollierte Ausnahme?

2. Ist RuntimeException eine ungeprüfte Ausnahme?

Hier ist mein Verständnis einer ungeprüften Ausnahme:

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4. Könnte der obige Code nicht auch eine geprüfte Ausnahme sein? Kann ich versuchen, die Situation auf diese Weise wiederherzustellen? Kann ich das? (Anmerkung: meine 3. Frage befindet sich innerhalb der catch oben)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5. Warum tun die Menschen das?

public void someMethod throws Exception{

}

Warum lassen sie die Ausnahme aufsprudeln? Ist es nicht besser, den Fehler früher zu behandeln? Warum aufblähen?

6. Soll ich die genaue Ausnahme aufblasen oder sie mit Exception maskieren?

Im Folgenden finden Sie meine Lektüre

Wann sollte ich in Java eine geprüfte Ausnahme erstellen, und wann eine Laufzeitausnahme?

Wann sind kontrollierte und nicht kontrollierte Ausnahmen zu wählen?

Answer 1

Abgehakt - Kann vorkommen. Überprüft in der Kompilierzeit.

Beispiel. FileOperations

Nicht angekreuzt - Aufgrund von schlechten Daten. Geprüft während der Laufzeit.

Beispiel.

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

Hier ist die Ausnahme auf fehlerhafte Daten zurückzuführen und kann in keiner Weise während der Kompilierungszeit bestimmt werden.

Answer 2

Geprüfte Ausnahmen werden zur Kompilierzeit von der JVM geprüft und beziehen sich auf Ressourcen (Dateien/DB/Stream/Socket usw.). Das Motiv der geprüften Ausnahme ist, dass die Anwendung zur Kompilierungszeit ein alternatives Verhalten definieren sollte, um dies im catch/finally-Block zu behandeln, wenn die Ressourcen nicht verfügbar sind.

Ungeprüfte Ausnahmen sind rein programmatische Fehler, falsche Berechnungen, ungültige Daten oder sogar Fehler in der Geschäftslogik können zu Laufzeitausnahmen führen. Es ist absolut in Ordnung, ungeprüfte Ausnahmen im Code zu behandeln/abzufangen.

Erläuterung entnommen aus http://coder2design.com/java-interview-questions/

Answer 3

Um die letzte Frage zu beantworten (die anderen scheinen oben ausführlich beantwortet worden zu sein): "Soll ich die genaue Ausnahme aufblasen oder sie mit Exception maskieren?"

Ich nehme an, Sie meinen so etwas wie das hier:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

Nein, deklarieren Sie immer die am genauesten Ausnahme möglich, oder eine Liste von solchen. Die Ausnahmen, die Sie Ihrer Methode zugestehen, sind Teil des Vertrags zwischen Ihrer Methode und dem Aufrufer. Das Werfen von "FileNotFoundException" bedeutet, dass es möglich ist, dass der Dateiname ungültig ist und die Datei nicht gefunden wird; der Aufrufer muss dies intelligent behandeln. Das Werfen von Exception bedeutet: "Hey, Scheiße passiert. Deal." Das ist eine sehr schlechte API .

In den Kommentaren zum ersten Artikel finden sich einige Beispiele für "Würfe Exception " ist eine gültige und vernünftige Erklärung, aber das ist nicht der Fall für die meisten " normal "Code, den Sie jemals schreiben werden.

Answer 4

Meine absoluter Favorit Eine Beschreibung des Unterschieds zwischen ungeprüften und geprüften Ausnahmen findet sich im Java-Tutorial-Trail-Artikel, " Unkontrollierte Ausnahmen - die Kontroverse "(es tut mir leid, dass ich in diesem Beitrag so elementar werde - aber manchmal sind die Grundlagen die besten):

Hier ist die wichtigste Richtlinie: Wenn ein Kunde vernünftig sein kann erwartet werden kann, dass er sich von einer Ausnahme erholt, machen Sie sie zu einer geprüften Ausnahme. Wenn ein Client nichts tun kann, um sich von der Ausnahme zu erholen, machen Sie sie zu einer ungeprüfte Ausnahme

Der Kern der Frage, welche Art von Ausnahme geworfen werden soll, ist (bis zu einem gewissen Grad) semantischer Natur, und das obige Zitat bietet einen hervorragenden Leitfaden (daher bin ich immer noch hin und weg von der Vorstellung, dass C# geprüfte Ausnahmen abgeschafft hat - zumal Liskov für deren Nützlichkeit argumentiert).

Der Rest ist dann logisch: Auf welche Ausnahmen erwartet der Compiler, dass ich explizit reagiere? Diejenigen, von denen Sie erwarten, dass sich der Client erholt.

Answer 5

Ich denke, dass geprüfte Ausnahmen eine gute Erinnerung für den Entwickler sind, der eine externe Bibliothek verwendet, dass in Ausnahmesituationen Dinge mit dem Code aus dieser Bibliothek schief gehen können.